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(57) A BD-ROM contains a plurality of titles which 
can be branched among, and a Java application. The 
Java application is a progr^n described in a program- 
. ming language for a virtual machine. A life cycie where 



n by the virtual machine Is enabled is predeter- 
mined. Eadi of the titles contains an appHcatlon man- 
agement table indicates an application that has a life cy- 
cle bound to the title. 
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Description 

Technical Fieid 

[0001] The present invenUon belongs ;o a field of play- s 
back control technology for simultaneously executing an 
application and pSayback of a digitized movie work, and 
in particular reiates to an applied technique for appljHng 
the playback control technique to a reconding medium, a 
consumer playback apparatus and a program. 'o 

Background Art 

[0002] In the movie business !hat uses recording me- 
dia, there is a sales strategy v/hereby a digitized movie 's 
work and an application for online shopping are sold re- 
corded on a same recording medium. The creator has 
an expectation that by incorporafing a mechanism for 
sailing character goods relating to ttie movie work online 
on the one recording medium, the synergy effect of the ?o 
movie work and theapplicationwili increase sales of the 
character goods. Torealize such contents, there is a de- 
sire that upcoming recording media and playback appa- 
ratuses be equipped with an appltoation execution envi- 
ronment that has a greater degree of freedom. 
[COOS] In order to realize simultaneous execudon of 
such a movie work and online shopping application, a 
technique is required to execute the application in ac- 
cordance with playback of digital video. One known tech- 
nique for executing Java ^plications is "signaiing" set 30 
forth in the DVO-MHP specification. Signaling involves 
defining, on a playback time a»s of a digital stream, a 
start point at wfiich She application is to be run and an 
end point at which the application is to be tonminated, 
transmitting information called an AIT (Explication infor- 3S 
mation table) at this point, and causing the playback ap- 
paratus to perform control In accordance with this AIT. 
[0004] However, regression of the playback time axis 
may occur in the procession of playback. This means 
tiiat playback proceeds In the reverse direction of the -lo 
time axis due to Backward play. If regression and pro- 
gression back and forth of the content is repeated with 
the point at which the application should be run and the 
point at which the application should be temiinated being 
reversed, loading and discarding to and from the work is 
memory will also be perfomied numerous times, thus 
causing and excessive load for reading. 

Disclosure of the Invention 

so 

[0005] An object of the present Invention is to provide 
a playback apparatus capableof avoiding excessive load 
f orreadin gwhen pi ayback reg resses on th e playback time 

[0006] The stated object is achieved by a recording S5 
medium on which is recorded a pluraiity of titles between 
which branching is possible, and at least one application, 
wherein each application is a program written in a virtual 
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machine-oriented progfamming language, and a !ife cy- 
cle in which each appllcaUon can be executed by a virtual 
machine is specified in advance, each title includes a 
management table, and eadi management table shows 
one or more of the appiications that has a life cycle bound 
to the title. 

[0007] Each title is composed of a time axis and a con- 
trol procedure, and brarahing from one title to another is 
defined with a branch command. Therefore, if backward 
piay is performed on the Ume axis of one title, pla)*ack 
does not regress back to the branch origin title that was 
played before the branch occun'ed due to the brandi 
command. !f a title is freated as being a unit in which 
regression of playijack is not possible, and the life cycle 
of an application is define based this title, this will avoid 
repeated reading to discarding from the work memory. 
Since repeated reading and discarding is eliminated, ex- 
cessive load for reading is avoided. 

Brief Description of the Drawings 

[OOOSJ 

FIG. 1 shows a usage act of a recording medium 
pertaining to ttie present invention; 
FIG. 2 shovys a file/directoiy staictufs of a BD-ROM; 
FIG. 3 shows the relationship between an AVClip 
time axis and a PL time axis; 
FIG. 4 shows a batch specification achieved by four 
Clip_infomiation_file_names; 
FIG. 5 shows definition of chapters by PLmarlcs; 
FIG. 6 shows synchronization specification and def- 
inition of a plairtack period on the SubPlay Item time 
axis; 

FIG. 7A shows the internal structure of the Movie 
Object; 

FIG. 78 shows the internal structure of a BD-J object; 
FIG. 7C shows the internal structure of a Java ap- 
plication; 

FIG. 8A shows programs and data stored in Java 
archive files; 

FIG. 88 shows an example of an xlet program; 
FIG. SAshowsaseriesofTrtles: atc^menu, TiUe#1 
andTrtle#2; 

FIG. 98 shows a time axis that is the time axes of 
Tit!e#1 andTit!e#2 added together; 
FIG. 10 shows a disc content that includes three Ti- 
tles: a main Title; an online shopping Title; and a 
game Trtle; 

FIG. 11 shows an example of playback images of 
the three Titles shown in FIG. 10; 
FIG. 12A ^ows the life cycle of each application, 
which is drawn based on the belonging relationships 
shown by the broken-line frames of FIG. 1P; 
FIG. 1 2B shows an example of application manage- 
ment tables written for specifying the life cycies of 
FIG. 12A; 

FIG. 13A shows an example of setting of run at- 
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^butes; 

FIG. 13B shows an application (application#2) that 
is not run until a ca!l is received for the application 
fronn another application; 

FIG, 14A and 14B show an exampie of application 5 
management tables and iiSe cycles when 'Suspend* 
is effective; 

FIG. 1 5 shows combinations of the three run at- 
tftoutes (Persistent, AutoRun, and Suspend) and 
three possible statuses of the previous Title (Not to 
Run, Running, and Suspend); 
FIG. 16 shows the internal stmcture of the playback 
apparatus v of the present invention; 
FIG. 1 7A shows how Java archive files stored on the 
BD-ROM are identified in a local memory 29; is 
FIG. 17B shows application of FIG, 17A; 
FIG. 18 shows, in the layer stmctu re, the harcfware 
and the software stored in a ROM 24; 
FIG. 19 is an iilustration of the processes perJomied 
by a presentation engine 31 to a moduie manager 34; ^ 
FIG. 20 illustrates processing by an application man- 
ager 36; 

FIG, 21 shows a work memory 37 to a default oper- 
ation manager 40; 

FIG. 22 shows control procedures of the application ss 
manager 36 for branching; 
FIG. 23 is a flowchart showing procedures of 
processing for terminating ^plications; 
FIG, 24 indicates the process f or tenntnating appli- 
cations; so 
FIG. 25A shows an application management table 
that defines life cycles on the PL time axis; 
FIG. 25B shows life cycles of applications based on 
the application management tables of RG. 25A; 
FIG . 26A shows a Title time axis set based on a PL 35 
time axis; 

FIG, 26B shows the Title time axis set based on the 

life cycle of a main application; 

FIG. 26C shows a Title time axis set based on the 

life cycle of a plurality of applications; -lo 

FIG. 27 is a flowchart lowing the procedure for 

processing by &ie application manager 36 in Title 

playback; 

FIG. 26A shows a menu hierarchy realized on a BD- 
ROM; "S 
FIG. 288 shows a MOViEobjectfor tunning the men- 
us having the hierarchy; 

FIG. 29 Illustrates sn Index Table, and branching 

from ttie Index Table to Movie objects; 

FIG. 30A shows branching when the indexTable is so 

written as shown in FIG. 29B: 

FIG. 303 shows branching when a non-AV title is 

forcedly temitnated; 

FIG. 31 is a flowchart showing the procedure for 
processing by the module manager 34; ss 
FiG. 32 shows an operation example when the ap- 
plication manager 36 forcedly terminates an appli- 
cation; 



FIG, 33 is a flowchan showing a PL playback proce- 
dure by the playback control engine 32; 
FIG. 34 is a flowchart showing an angle switch pro- 
cedure and a SkipBack and SkipNext procedure; 
FIG. 35 is a flowchart showing processing when a 
SkipBack or SkipNext API is called; 
FIG. 36 is a flowchart showing details of processing 
by the presentation engine 31 ; 
FIG. 37 is a ftowchart showing a SubPiayitemplay- 
back procedure; 

FIG. 38 is a flowchart showing processing by the 
application manager 36 in the fifth embodiment; 
FIG. 39 shows an exampie of a data management 

table; 

FIG. 40 shows an execution model that assumes a 
BD-J object; 

FIG. 41A shows life cycles of showing life of Java 

archive files in the local memory 29; 

FIG. 4 1 B shows data management tables written for 

specifying the Java anshive file life cycles of FIG. 

41A; 

FIG. 42 shows Java archive files embedded accord- 
ing to the carousel mettiod; 
FIG. 43A shows an AVClIp embedded according to 
interleaving; 

FiG. 43B shows three types of read attributes; 
FIG. 44A shows an example of a data management 
table; 

FiG. 44B shows changes in the storage content of 
the iocal memory 29 according to allocation by the 
data management table; 

FIG. 4SA shows a comparison of memory scales of 

the iocal memory 29 in both a new playback appa- 

rattjs and an old p!ai*ack apparatus; 

FiG. 458 shows an ex^pie of a data management 

table in which read priority levels are set; 

FtG. 4 e shows pnicessing for preload control by the 

application manager 36; 

FIG. 47A shows an exampie of a data management 
table of a data management table that specifies a 
plurality of applications that have identical af^lica- 
tionlDs but mutually different read priority levels; 
FIG. 47B changes in the storage content of the iocal 
memory 29 according to allocation by the data man- 
agement table of FIG. 47A; 
FIG. 48A shows an example of a data management 
table written such that the same applicationlD is giv- 
en to applications that are to be preloaded and ap- 
plications that are to be loaded; 
FIG. 486 shows changes in the storage content of 
the local mwnory 29 in a playback apparatus having 
a small memory scale; 

FIG. 48C shows changes in the storage content of 
the local maifiory 29 in a playback apparatus having 
a large memory scale; 

FIG. 49 shows the procedure for load processing by 
the application manager 36 based on a data man- 
agement table; 
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FIG. 50 shows the processing procedure of the ap- 
plication manager 36 when a current pSayback posi- 
tion reaches the life cycle of an application q; 
FIG. 51 illustrates how the Java virtual machine 3B 
reads appSications; 

FIG. 52A shows the interna! stnjcture of a BD-J ob- 
ject relating to a seventh embodiment; 
FIG. 52B shows an example of a PiayList manage- 
ment table: 

FIG. 52C shows how the playback apparatus proc- 
esses in a case of a PL existing whose playback 
attribute is set to "AutoPlay" in the PiayList manage- 
ment table of a branch destination Title; 
FiG. 53A shows the Trtie time axis of a non-AV Title 
in a case of the playback attribute being set to show 
non-automatic playback; 

FIG. 53B shows a Title time axis of a non-AV Title 
for which the playback attribute is set to AutoPiay; 
FIG. 63C shows a case of the pla)*ack attribute be- 
ing set to show "AutoPlay" in the PiayList manage- 
rnent table, and the application terminating abnor- 
mally; 

FiG. 53D shows a case of the playback attribute be- 
ing set to show "AutoPlay" in the PiayList manage- 
ment table, and the main application failing to run; 
FIG. 54 is a flowchart showing processing by the 
application manager 36 relating to the seventh em- 
bodiment; 

FIG, 55 illustrates how playback is performed with 

the playback attribute being set to 'AuSoPlay" in the ■ 

PiayList management tabie; 

FIGs. 56A and 568 show the relationship between 

run attributes and the treatment of s^jplications; 

FIG. 57 illustrates how the Java virtual machine 38 

of the eighth embodiment reads af^licatlons; 

FIGs. 58 A and 588 show an example of the read 

priority levels of the ninth embodiment; 

FIG. 59A shows a data management table in which 

group attributes are assigned; 

FIG. 598 shows access to the local memory 29 ' 

based on an application management table; and 

FIG. 60 shows variations of ttie units of allocation of 

application management tables. 

Best l^ode for Carrying Out the Invention < 

(First Embodiment) 

[0009] The following describes an enrtiodiment of a 
playback apparatus of the present invention. Firstly, of i 
the implementation acts of the playback apparatus of the 
present invention, a usage act is described. FIG. 1 shows 
a usage act of a playback apparatus of the present in- 
vention. In FIG. 1 , the playback apparatus of the present 
invention is a playback apparatus 200 which together ^ 
with a television 300 and a remote controller 400 foims 
a home theater system. 

[0010] A BD-ROM 100 is used to supply movie 'works 



in the home theater system fomied from the playback 
apparatus 200, the remote controller 300, and the tele- 
vision 400. 

[0011] This completes the description of the usage act 
of the piayfaack af^aratus of the present invention. 
[0012] The following describes the BD-ROW that is a 
recording medium played by the playback apparatus of 
the present invention. Disc content supplied to the home 
theaterbythe BD-ROM iscomposed of a plurality of Titles 

' that branch between each other. Each Title is made up 
of at least one PiayList and a dynamic control procedure 
that uses the at least one PiayList. 
[0013] A PiayList is composed of at least one digital 
stream and a playback paWi of each digital stream, and 

> is the unit of access on a BD-RO!^ that has a concep- of 
a "time axis". Since it incorporates a PiayList and a dy- 
namic control procedure, a Tttle has both the concept of 
a tinne axis that is characteristic of digital stream, and the 
properties of a computer preigram. 

' [0014] FIG. 2 shov/s a f iSe/directory structure of a BD- 
ROM, The BD-ROM in FIG. 2 has a BDMV directory be- 
low a Root directory. 

[0015] Th e BDMV directory has files with the extension 
"bdmv" (index bdmv. Movie Object.bdmv), and files with 
the extension *BD-J* (OOOOl.BD-J. 00002.BD-J, 
00003.BD-J). Under the SDtviV directory, there are four 
sub-directories: PLAYLiST. CLIPINF, STREAfi^, and 
BDAR directories. 

[0016] The PLAYLIST directory has files with the ex- 
tension *mpls" (00001. mpis, 00002.mpls, 000O3,mpis). 
[001 7] The CLIPINF directory has files with the exten- 
sion "dpi" (00001 .dpi, O0002.clpi, OOOOS.dpi). 
[0Q18J The STREAM directory has files with the exten- 
sion •m2ts" (00001 .m2ts. O0002.m2ts, OOO03.m2ts). 
[001 9] The BDAR directory has files with the extension 
"jar" (00001 .jar, OD002.]ar. 00003.jar). As this description 
shows, the directory structure enables different types of 
flies to be recorded on a BD-ROM. 
[0020] In FIG. 2. the files with the extension ".m2ts* 
(00001 .m2ts, O0002.m2ts, 00003.m2ls...) contain AV- 
Clips that are classified into types such as MainClip and 
SubClip. A MainClip is a digital stream that is obtained 
by multiplexing a plurality of elementary streams such as 
a videos&eam, an audio stream, apresentation graphics 
stream and an interactive graphics stream. 
[0021] A SubClip is a digital stream that corresponds 
to one elementary stream such as an audio stream, a 
graphics stream, or a text subtitle stream. 
[0022] The files with tine extension 'dpi' (0000 1 . dpi, 
O0002.c^i, 00003.clpi ...) are management Infonriation 
that conrespond one-to-one with the AVCIips. Since it Is 
management Infonnation, Clip information has informa- 
tion such as the encoding format, frame rate and bit rate 
of the stream in the AVCiip, and an EP^map th^t shows 
cue locations. 

[0023] RIes with the extension "mpis" (00001 .mpis, 
00002, mpIs, 00003 .mpis...) contain PiayList InfonTia- 
tion. PiayList infomiation is information that defines a 
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PlayList with reference to an AVClip, A PlayList is com- 
posed of MainPath information, PLiMark information and 
SubPath information, 

[0024] The MainPath infonnation contains a plurality 
of pieces of Play Item information. The Play Item is a play- 
back period that is defined by specifying In-Time and 
Out-Time on one or more AVClip axes. An arrangement 
of a plurality of pieces of Playltem infomnation defines a 
PlayList (PL) that is composed of a plurality of plajrtjack 
periods. FIG. 3 shows the relationship between an AV- 
Clip and a PL, The firet row indicates the time axis of the 
AVClip, and the second row indicates the time axis of the 
PL. The PLinfonriation includes three pieces of Playltem 
infonnaUon: "Playitem #1 ", "Piayltem #2", and "Playltem 
#3", The ln_flmes and Outjimes of Playltem #1 , #2, and 
#3 define three playback periods. By an*ang!ng the three 
playback periods, a time axis that is different from the 
AVClip time axis is defined. That is the PL time axis shown 
in the second row. As is apparent from this, it is possible, 
by defining the Playltem information, to define a time axis 
that is different from an AVClip time axis. 
[0025] in principle, only one AVClip is specified. How- 
ever, a plurality of AVCIips may be specified by a batch 
specification. The batch specification is achieved by a 
plurality of Ciip_lnfomnation_file_names in the Playltem 
infonnation. FIG. 4 shows a batch specification achieved 
by four Clip_infomiat!on_f!le„names. In FIG. 4, the first 
to fourth rows indicate four AVClip time axes (time axes 
of AVClip #1 , #2, #3, and #4), and the fifth row indicates 
a PL time axis. The four time axes are ^ecified by the 
fourClip_lnfomiation Jile_names contained in tiie Piay- 
ltem Infomation. With such a construction, fourp!ai*ack 
periods, which can be selectively played, are defined by 
the ln_times and Outjimes contained in the Piayltems. 
This enables the PL time axis to define a period (what is 
called a multi-angle period) in which a plurality of switch- 
abie angle images are provided. 
[0026} The PLMark information is information that 
specifies, as a chapter, a given period on the PL time 
axis. FIG. 5 shows definition of chapters by PLmarks. In 
FIG. 5, the first row indicates the AVClip time axis and 
the second row indicates the PL time axis. In FIG. 5, 
arrows "pkT and *pk2° each indicate a specification of 
a Playltem {ref_to_P!ayltem_!d) and a specification of a 
point in time (mark_time_stamp) in a PLIWark. Witti these 
specifications, three chapters (Chapter #1 , #2, *3) are 
defined on the PL time axis. 

[0027] The SubPath information Is information com- 
posed of a plurality of pieces of Sub Playltem information. 
The SubPlayitem infomiation defines a playback period 
by specifying and an ln_Ttme and an Out_Time on the 
time axis of the SubClip. The SubPlayitem infomiation 
is used for a synchronization specification to synchronize 
a playback period on the SubClip time axis with the PL 
time axis. With the synchronization specification, the 
SubCltp time axis and the PL lime axis proceed in syn- 
chronization. FIG. 6 shows how the synchrodization 
specification and definition of a playback period on the 
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SubPlayitem time axis are done. In FIG. 6. the first row 
indicates the PL time axis, and the second row indicates 
the SubPlayitem time axis. In FIG. 6. SubPlayitem. IN_ 
time and SubPlayitem.Out_time indicate the start point 
•5 and end point, respectively, of the playback period. It is 
seen from this that the playback period is defined also 
on the SubCiip time axis. Tlie Sync_Playltem„ld corre- 
sponding to the arrow Sni indicates ttie synchronizaUon 
specification for a Playitem, and Sync_star1_Pts_of„ 
Playltem con-espondingtothe arrow sn2 indicates spec- 
ification of a point in time in the Playltem on the PL time 

[0026] The PlayList information in BD-ROM is charac- 
terized by Its ability to define a multi-angle period and a 

« synchronization period, where switching among a plural- 
ity of AVCIips is possible in the multi-angle period, and 
having an AVClip synchronized with a SubClip ispossible 
in the synchronization period. The above- described Clip 
information and PlayList infonnation are categorized as 

so "static scenario". This is because the Clip infonnation 
and PlayList Infomtiation define a PL that is a static play- 
back unit. This completes the description of the staKc 
scenario, 

[0029] The following describes Uie 'dynamic soenar- 

25 to". The dynamic scenario is scenario data that dynami- 
cally defines the playback control of an AVClip. Here, 
"dynamically" means that the playback control can 
change in accordance with a status change of the play- 
back apparatus or a key event from the user. BD-ROM 

30 presumes two modes as the operation environment for 
the playback control. The first mode is an operation en- 
vironment similar to the operation environment of the 
DVD playback apparatus, and is a command -based ex- 
ecution environment. The second mode is an operation 

35 environment of the Java Virtual Machine. Of these two 
operation environments, the first one is called HDMV 
mode, and the second one is called BD-J mode. Due to 
the presence of the two operation environments, the dy- 
namic scenario is written by presuming either of the two 

-If operation environments. Adynamicscenario presuming 
the HDMV mode is called Movie Object, and is defined 
by the management information. On the other hand, a 
dynamic scenario presuming tiie BD-J mode is cailed a 
BD-J Object. 

■*s [0030] First, the Movie Objectwill be described. 
<Movie Object> 

[0031] TTie Movie Object Is a component of a Tltie', 
so and is stored in afIle"MovIeObject.bdmv". FIC3.7Ashows 
■ • the internal structure of the Movie Object. The Movie Ob- 
ject is composed of attit>ute infonnation and a command 
sequence that consists of a plurafity of navigation com- 
mands, 

55 [0032] The attribute information is composed of infor- 
mation that indicates, when MenuCali has been per- 
fonned, whether or not playback should be resumed af- 
ter, on the PL time axis, MenuCal! is performed (resume„ 
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intentionjiag), information incEcatIng wheUier or not the 
^flenuCall should be masked on the PL time axis (menu_ 
call_mask), and infomnation indicating whetheror not Ti- 
ae search should be masked (title_searchjlag). Since a 
Movie Object has the properties of both a time axis and 
program-lilce control, numerous types of Titles, such as 
playback of a main feature, are written in a Movie Object. 
(00331 The navigation command sequence is a com- 
mand sequence for realizing conditional branching, set- 
ting of the status register in the playbad« apparatus, ob- 
taining a value set in the status register, and so on. The 
following are the commands that can be written in Movie 
Objects. ■ 

PlayPL command 

Fonmai: PlayPL (1st argument, 2nd argument) 

[0034] As the 1 St argument, a Plaj^ist number can be 
used to indicate a PL to be played back. As the 2nd ar- 
gument, a Playltem contained in the PL, a given time in 
the PL. a Chapter, or a Mark can be used to indicate a 
playback start position. 

[0035] A PlayPL function thatspedfies a playback start 
position on the PL time axis using a Piayltem Is calied 
PlayPLatPlay(tem(). 

[0036] A Play PL function that specifies a playback start 

position on the PL time axis using a Chapter is called 
PlayPLatChapter(). 

[0037] A PlayPL functionthatspecifies apiaybackstart 
position on the PL time axis using time information is 
c^led PlayPLatSpecifiedTimeO. 

JMP command 

Fonnat: JMP argument 

(0038] The JMP command is used for a branch that 
discards a currenliy executed dynamic scenario and ex- 
ecutes a branch destination dynamic scenario that is 
specified by the argument There are two types of JMP 
command: a direct reference type that directly specifies 
the branch destination dynamic scenario; and an indirect 
reference type that indirectly refers to the branch desti- 
nation dynamic scenario. 

[0039] The description fomiat of the navigation com- 
mand in the Movie Object resembles that in DVD. For 
this reason, disc content can be transplanted effteientiy 
from a DVD onto a BD-ROM. The Movie Object is a prior 
art disclosed in the following International Publication. 
For details, refer to the International Pubfication. 

International Publication WO 2004/074976 

[0040] This completes the description of the Movie Ob- 
ject. The following describes the BD-J object. 



<8D-J Object> 

[0041] The files with the extension BD-J (00001 .BD-J, 
00002.BD-J, 00003.BD-J) each compose a BD-J object. 

5 A BD-J object is a dynamic object in BD-J mode, which 
is written in a Java programming environment. FIG. 7B 
shows the interna! structure of a BD-J object As shown 
in FIG. 7B. the BD-J object consists of attribute informa- 
tion identical to that of the Movie Object, and an applica- 

0 tionmanagementtable.The BD-Jobjectisapproximately 
the same as the Movie Object in that it includes the at- 
tribute information. The difference from the Movie Object 
is that a command is not written directly in the BD-J Ob- 
ject, That is to say, in the Movie Object, the control pro- 
's cedure is written directly in the navigation commands. In 
contrast, the BD-J Object indirectly defines the control 
procedure by allowing a spec'rTfcation for a Java applica- 
tion that uses the Title as a life cycte to be set in an ap- 
plication management tabie. Such an indirect definition 
20 provides an efficient sharing of a common control proce- 
dure, allowing a plurality of Titles to share the common 
contro! procedure. 

[0042] FIG. 7C shows the internal structure of a Java 
application. The application shown in FIG. 7C includes 

£5 one or more xlet programs that are loaded in the heap 
area (also calied v/ork memory) of the virtual machine. 
The application is composed of the xlet programs loaded 
in the work memory, and threads. This completes the 
description of the structure of the application. 

30 [0043] The substantial body of the Java application is 
Java archive files. (00001 .jar, 00002. jar) that are stored 
in the BOAR directory under the BDMV directory. The 
following describes the Java archive files, 
[0044] The Java archive files (00001. jar, 00002.jar) 

35 each contdn a program that composes e Java applica- 
tion, and data. FIG. 8A shows the programs and data 
stored in ttie archwe files. The data shown in Fig. 8A has 
been configured by the Java archive by arranging a plu- 
rality of files into the directory structure indicated fay the 

'>o oval frames. Th e directo ry structure indicated by the oval 
frames is composed of the Root, java, and image direc- 
to ries. The common.pkg is arranged to be under the Root 
directory, the ciass flies (aaa.class, bbb.class) are ar- 
ranged to be under the java directory, and menu, jpg is 

^5 arranged to be under the image directory. The Java ar- 
chive files are each formed by the Java archive by com- 
bining such files into one. Such data is expanded when 
it is read from the BD-ROM. and is treated as files ar- 
ranged in the directories in the cache. The five-digit 

50 number "xxxxx* attached to each Java archive file name 
indicates an ID of an application (applicationID). When 
such a Java archive file has been read to a cache, it Is 
possible to extract programs and data that constitute an 
arbitrary Java application by referring to the number at- 

55 tached to the file name, 

[0045] In the Java archive file, xtet programs are ar- 
ranged into one file, 

[0046] An xlet program is a Java program that can use 
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a JMF (Java Media Framework) interface. The xlet pro- 
gram is composed of a pSurality of functions sucti as 
EventUstner for receiving key events, and executes 
processing in correspondef>ce with the received l<ey 
events in accordance with a format such as JMF. s 
[0047] FIG, 8B shows an exan^le of an xiet program. 
JMF A 'aDj/ZOOOOl .mpis'; is a nfieUiod that instructs the 
Java virtual machine to generate a player instance to 
play a PL. A.play Is a method that instructs playback of 
the JMF player instance. The JMF player instance is gen- if 
erated based on a JMF library. The xiet program is not 
limited to being written as a JMFfora PL of the BD-ROM, 
but may be written as a JMF appiic^le to entire content 
that has a time axis. This ability to write in this way en- 
courages software houses dealing with Java program- « 
ming to create BD-J objects. 

[0048] Jump TitieO; in FIG. 8B Is a call for a function 
APL This function API instnjcts the playback apparatus 
to branch to another Tide (TitleSI in FIG. SB). This func- 
tion API {Application Interface) is supplied by the BD- so 

playback apparatus. In addition to the JumpTltle 
connmand, the xlet program can instnjct the BD-ROM 
playback apparatus to execute pnacesses that are u nique 
to the SO-ROM playback apparatus by writing calls for 
function APIs. 25 
[0049] PL playback in BO-J mode Is stipulated by the 
JMFintefface. Since the JMF player instance detennines 
the PL time axis, the Title time axis is determined based 
on the Titie that includes this JMF player instance. Fur- 
thermore, branches from Title to Title in BD-J mode are so 
Stipulated by a call of a JunpTitieAPI. The JumpTrtleAPl 
call detenmines the end point of the TWe. Therefore, an 
application that includes such a JMF player instance and 
JumpTitleAP! call governs starting and ending of Titles 
In BD-J mode. as 
[0050] The above is a description of dynamicscenarios 
in BD-J mode. A Title that incorporates both PL playback 
and progtam-iike control Is defined by a dynamic scenar- 
io in this BD-J mode. It should be noted here Uiat although 
in the present embodiment programs and data that con- <o 
stftute the application are stored in Java archive files, 
such programs and data may be stored in L2H files or 
zip files. 

<Title time axts> 'is 

[0051] Having completed the description of the static 
scenarios and dynamic scenarios that compose the Ti- 
tles, the following describes what kind of time axis these 
define. The time axis defined by a Title is called a 'Title so 
time axis". The Title time axis Is composed of PLs, play- 
back of the PLs being instructed by Movie objects or BD- 
J objects. Titles such as that of FIG. 9A are given here 
as one example. These Titles are a series of Titles: top 
menu, TitieSI , Tide#2, top menu, top menu, Title#3, top ss 
menu. Of these Titles, if Title#1 instmds playback of 
PlayList#1 and PlayList#2, T1fleS2 instructs playback of 
PlayList#3. and Title#3 instructs playback of PlayList#4. 



Title#1 has a time axis that corresponds the total of tinrie 
axes of PlayListSI and PlayList#2, as shown in FIG, 98. 
Similarly, Titie#2 has a time axis that corresponds to the 
time axis of PlayUstS3, and Title#3 has a time axis that 
con-esponds to the time axis of PlayUst#4. Although 
seamless playback is guaranteed on each PL time axis 
in these Title time axes, it is not necessary to guarantee 
seamless plaj^ack in the Trtle time axes. To operate Java 
applications, it is necessaiy to define a period for whch 
Java applications may exist in the woit memory of the 
virtual machine (service period) on the Title time axis. To 
operate Java applications in BD-J mode, it is necessary 
to define a service period of Java applications on a time 
axis on which the applications mutually branch. Defining 
of these service periods must be kept in mind when pro- 
gramming for BD-ROMs. 

[0052] Finally, adescription is given of IndexTablecon- 
tained in index.bdmv. The IndexTable is a table in which 
Title numbers, Movie Objects and BO-J objects are in 
correspondence, and is an indirect reference table re- 
fen-ed to when branching from dynamic scenario to dy- 
namic scenario. The IndexTable is composed of a plu- 
rality of Index that con-espond respectively to a plurality 
of labels. Written in each Index is an identifier of a dy- 
namic scenario corresponding to the label. Referring to 
this IndexTable realizes brandling without strict differen- 
tiation between Movie objects and BO-J objects. Tlie In- 
dexT^le Is disclosed in Oie following IntemaSonal Pub- 
lication. Fordetails, refertothe International Publication. 

International PublicaUon WO 2004/025651 A1 

[0053] Tn\s completes the description of the files re- 
corded on the BD-ROM. 

■^Application Management Table> 

[0054] As descrtoedabove, applfcations that have J M F 
player instancas and JumpTltleAPl calls govern the Title 
time axis. When other appncations that do not have JMF 
player instance and JumpTrtleAPl call are nin, it is im- 
portant to cleariy define, on the tme axis, the start point 
at which service by an applk;afion starts and the end point 
at which service by the application ends. In the present 
embodiment, the start through to the end of service of a 
service by an application is defined asjhe "life" of an 
application. The information for defining the life of appli- 
cations exists in ^plication management tables In BO- 
J objects, The following describes the application man- 
agement table in more detail. 

■ [0055] The application management table (AMT) is in- 
formation showing applications that may exist in the work 
memory of the virtuai machine, represented with the Title 
time axis of each Trtle. Living in the wori< memory refers 
to Uie xlet programs composing the application having 
been loaded in the work memory such thatthe application 
can be executed by the ^rtual machine. The broken line 
arrow at1 In FIG. 7Bshows acloseup of iheintemalstruc- 
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ture of (he appiication management table. As shown in 
tiiis interna! stnjcture, the application management table 
consists of 'life cyoie", *appllcatlon !0" wtiteh shows an 
af^lioation that has a life cycle bound to the Title, and 
'run attribute' of the application. 
[0056] The following describes the life cycle is written 
in the application management table, using a specific ex- 
ample which includes a disc content that will be imple- 
mented in the near future, as the material. The disc con- 
tent used as the material rndudes three different types 
of Titles: a main Title (T(tle#i> that constitutes a main 
image work; an online shopping Title (T1tle#2) that con- 
stitutes online shopping; and a game Trtle (Tit!e#3) that 
constitutes a game application. FIG. 10 shows a disc 
content that includes three Titles: a main Title; an online 
shopping Title; and a game Ttle. The left-hand side of 
FIG. 10 shows an IndexTable, and the right-hand side of 
FIG, 1 0 shows three Tittes. 

[0057] TTie brol<en-line frames on the right-band side 
of FIG. 10 show belonging relationships that Indicate Ti- 
tles towhich eachapplication belongs. Of the three Trtles, 
Til!e#1 is composed of application #1 , application #2, and 
application #3. Also, Title#2 Is composed of application 
#3 and application #4, and Tltle#3 Is composed of appli- 
cation #5. FIG. 1 1 shows an example of playback images 
of the three Titles shown in FIG. 10. In these playback 
Images of the three TitI es , video (cart crl ) 1 that simulates 
a shopping cart exists in the main Title of FIG. 1 1 A and 
the online shopping Title of FIG. n B, while the cart video 
does not exist In the.game Ttle of FIG. 110. Since the 
cart crl must be shown in both the main Title and the 
online shopping Title, applicationfJS, which is a cart pro- 
gram, is run with both Titie#1 and Ttie#2. Besides the 
described cart, otherapplications that run with a plurality 
of Titles in this way include an agent application that sim- 
ulates a mascot that appears in 8ie movie, and a menu 
application that displays menus in accordance with menu 
call operations. 

[0058] TTie belonging relationships shown by She bro- 
Icen-line fr^es of FIG. 10 appear as in FIG. 12A when 
e>q3ressed with a graph. In F!G. 12A, Uie horizontal axis 
indicates a Title time axis, and life cycles of applications 
are arranged In the vertical axis direction. Here, appiica- 
tion #1 and application #2 belong only to TrtleiSI, and 
therefore th e life cyoSes of th ese applications are conf i n ed 
to Titie#1. Application #4 belongs only to T5tle#2, and 
therefore the life cycle of application #4 is confined to 
Tit!e#2. Application #5 belongs o nly to Trtle#3, andthere- 
fore the life cycle of application #5 is confined to Ttle#3. 
Application #3 belongs to Title #1 and Title #2. and there- 
fore the life cycle of application #3 extends across Trtles 
#1 and #2. The life cycles shown In FIG. 12A appear as 
in FIG. 12B when written in the application management 
tables for Titles #1 . #2, and #3. If the application man- 
agement tables are written in this way, application #1, 
application S2, and application #3 are loaded into the 
wo it memory when the pSayback of TitleSI is started. 
Then, when the playback of Tit!e#2 is started, applica- 



tions #1 and (f2 are deleted from the work memory, caus: 
ing only application #3 to rem^n. Similarly, It is possible 
to perfonr) control so that application #4 Is loaded into 
th e work memoiy when the playback of Title#2 is started. 

s and that applications *3 and #4 are deleted from the work 
memory when the playback of Trtle#3 is started. 
[0059] Further, it is possible to perfomi control so that 
application #5 is loaded into the work memory while T- 
tle#3 is played, and that application #5 is deleted from 

'0 the work memory when the playback of TitleS3 ends. 
[0060] With this construction, the number of times the 
applicaBons are loaded into the wotK memory is mini- 
mized. This is because If abrandi between Titles occurs, 
appilcatfons thai live in both the branch origin and brandi 

15 destination may be stored in the wori< memory, and ap- 
plications that do not live in the branch origin and live in 
only the branch destination may be loaded into the wori< 
memory. Such a construcfion that decreases the number 
of times data is loaded enables an unboundary applica- 

^ tlon, which is such an application that does not make one 
conscious about a boundary between Titles, to be 
achieved. 

[0061] Thefollowing describes the run attributes of the 
applications. The run attributes include: "AutoRun" indi- 
es eating that tiie appiication with this attribute is automat- 
ically fun; "Persistent" indicating that the application with 
this attribute Is not the target of the automatic run but 
may be stored in the work memory of the virtual machine; 
and "Suspend" Indicating that the application wiUi this 
3f> attribute is stored in the work memory of the virtual ma- 
chine but is not assigned the CPU power. 
[0062] AutoRun shows a life cycle indicating that when 
a corresponding Titie branches, the application is simu!- 
taneously loaded into the work memory and executed. 
3S When a Title branches to another Trtle, the management 
body (application manager) ttiat manages the applica- 
tions loads an application which lives In the branch des- 
tination Titie and whose run attribute has been set to 
AutoRun, into the work memory of the virtual machine, 
10 and executes the application. This means that the appli- 
cation is automatically run as the Titie branches. Appli- 
cations that set the mn attribute to AutoRun include ap- 
plications that have JMF player instance and JumpTi- 
tleAPI call. This is because it is this kind of application 
IS that governs the Trtle time axis, and the concept of the 
Title time axis will become blurred if this kind of applica- 
tion is not run automatically. 

[0063] The run attribute "Persistent' is a continuous 
attribute, and indicates that the status of the application 

so in the branch origin Trtle is maintained; This is also an 
^ attribute that indicates that the application can be loaded 
into the work memory. An application whose run attilbute 
is set to "Persistent" can be called from another applica- 
tion. When an application is called from another applica- 

ss tion that is being run, the management body (appiication 
manager) judges whether or not She application ID of the 
application is written in the application managementtable 
and whether or not the run attribute of the application is 
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set to "Persistent". If it is set to "Persistent" the manage- 
ment body bads the application into the work memory. 
If the application ID of the call destination appHcation is 
not written in ttie application managementtafale, tine man- 
agement body does not loadthe application into the worl< 6 
memory. OnSy an application whose run attribute is set 
to "Persistent' can be called from another application. 
[0064] 'Persistent' is a default run attribute that is as- 
signed when the run attribute is not cleaily specified. As 
a result, when the run attribute of an application is -" 
indicating no specification, it means that the mn attribute 
of the application is "Persistent". 
10065] The following describes how the run attributes 
are written in the applications of FiG, 11. FIGs. ISA and 
13B are an example of settings of run attributes for the 
three applications of FIG. 12. Of the three applications 
shown in FIG. 12, application#2 does not run unless there 
is an application call from another application as shown 
in FIG. 13B. The remaining applbation#1 and #3 run au- 
tomatically simultaneously with Trtie#1 . In this case, the so 
run attributes of the applications areset in the application 
management table such that applicationSI and applica- 
tion#3 have the run attribute "AutoRun", and ^plica- 
tion#2 has the r^n attribute "Persistent". With these set- 
tings, applbation^l and ^plication#3 are automatically 25 
loaded into the work memory and executed when Title#1 
is branched to. On the other hand, since it has the run 
attribute'Pereistent", application#2 is interpreted as hav- 
ing a negative meaning that application#3 is an applica- 
tion Uiat may be loaded into the work memory of the virtual so 
machine. Hence, apptication#2 is not loaded into the 
work memory of the virtual machine and executed unless 
there is a call from applicaton#1 . With the described I'rfe 
cydes and run attributes, the number of applications that 
may run on the vlrtuai machine is limited to no more than 3S 
four, and the total number of threads is limited to no more 
than 64. This ensures that the applications run stably. 
[0066] The following describes "Suspend". 
[0067} "Suspend" indicates that the application with 
this atUibute is assigned a resource but is not assigned 
CPU power. The attribute "Suspend" is effective, for ex- 
ample, in achieving the process of passing a side path 
while a game Title is executed. FIG. 14A and 148 show 
an example of when "Suspend" is effective. As shown in 
FIG, 1 48, there are three Titles (Titie#1, Trtle#2, Title#3), 
of which raeSI and rrtle#3 execute game applications, 
and the intervening Title#2 is a side path, and implements 
video playback. Execution of the game is suspended be- 
cause it is necessary to implement video p!a)^ack with 
the side path. Since the game application counts the so 
score and the ilke during the game, it is preferable that ■ ' 
the stored values of the resources are maintained before 
and after Tftle#2. in this case, the application manage- 
ment table is written such that the game applications are 
suspended at the start point of Title#2, and application#2 ss 
resumes at the start point of Titie#3. This means that 
resources are assigned to application#2 during Titie#2, 
and therefore the stored values of the resources are 



maintained. However, since CPU power is not assigned 
to appl!cation#2, application#2 is not executed by the vir- 
tuai machine. This enables processing for executing the 
side path processing to be realized during execution of 
the game Titles. 

[0068] FIG. 15 shov/s combinations of the three run 
attributes (Persistent, AutoRun, and Suspend) and three 
poss^jle statuses of the previous Tftle(NotRun, Running, 
and Suspend). If the previous status is "Not Run* and 
the run attribute is "AutoRun" . the application is run in 
the branch destination Title. 

[0069] If the previous status is "Not Run" and the ain 
attribute is "Persistent" or'Suspend*. no operation Is ger- 
formed, and the status is maintained. 
[0070] If the previous status is "Running" and the run 
attribute is "Persistent" or "AutoRun" , no operation is 
perfomied, and the status in maintained. 
[0071] If the run attribute is set to "Suspend", the status 
of the application is suspended. If the previous status is 
"Suspend" and the run attribute of the branch destination 
Title is "Suspend", "Suspend" is maintained. If the previ- 
ous status is "Suspend" and the run attribute of the 
branch destination Title is "Persistent* or "AutoRun", the 
appiicaUon is resumed in the branch destination Title. 
Defining life cycles and run attributes in the appiication 
management table makes !t possible to perform a syn- 
chronization control to mn a Java appiication during a 
Title playback period, This enables various applications 
to be provided that cause images to be played and pro- 
grams to be executed. This compietes the description of 
the recording medium. The following describes the play- 
back apparatus of the present invention. 
[0072] FIG. 16 shows the internal structure of the play- 
back apparatus of the present invention. The playback 
apparatus of the present invention is industriallymanu- 
factured based on the internal structure shown in FIG. 
16. The playback apparatus of the present invention is 
mainly composed of two parts: a system LSI; and a drive 
apparatus. The industrial manufacturing is achieved by 
mounting the parts into the cabinet and on the board of 
the af^aratus. Tlie system LSI is an integrated circuit 
that includes various processing units for perfomiing the 
functions of the playback apparatus. The playback ap- 
paratus manufactured in such a manner includes a BD- 
ROM drive 1, a read buffer 2, a demultiplexer 3, a video 
decoder 4, a video plane 5, a P -graphics decoder 9 , a 
presentation graphtos plane 10, a combining unit It, a 
font generator 12, an l-graphics decoder 1 3, a switch 14, 
an interactive graphtes plane 15, a combining unit 16, an 
HDD 17, a read buffer 18, a demultiplexer 19, an audio 
decoder 20, a scenario memory 21, a CPU 22, a key 
event processing unit 23. an instruction ROM 24, a switch 
25, a GLUT unit 26, a GLUT unit 27. a PST set 28, and 
a local memory 29. 

[0073] The BD-ROM drive 1 perfomis loading/ejecting 
of a BD-ROM, and accessing of the BD-ROM. 
[0074] The read buffer 2 is a FIFO memory in which 
TS packets read from the BD-ROM are stored i n the Firet- 
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In-Rrst-Out manner. 

[0075] The demultiplexer (De-mux) 3 extracts TS 
packets irom the read buffer 2, and converts the TS pack- 
ets into PES packets. The demultiplexer 3 outputs PES 
padcets, outofthePESpackets obtained by the con ver- s 
sion, that have PIDs set by the CPU 22, to any of the 
video decoder 4, the audio decoder 20, the P-graphics 
decoder 9, and the l-graphics decoder 13. 
[0076] The video decoder 4 decodes a plurality of P ES 
packets, which ere output from the demultiplexer 3, into lo 
picujres of a non-compression fomiat, and writes the pic- 
tures onto the video piane 5. 

[0077] The video plane 5 is a plane for storing non- 
compression format pictures. The plane is a memory ar- 
ea in the playback apparatus for storing pixe I data of one '5 
screen, if aplurality of planes are provided in the playback 
apparatus, and the pixels of She data stored in each plane 
are added to Uie pixels of the data stored in other planes 
before video is output, video that is a combinafion of a 
plurality of video data can be output TTie resdution of 
the video plane 5 is 1 920 x 1 080. The picture data stored 
in the video plane 5 is composed of pixel data that is 
represented in 16-bit YUV values, 
[0078] The P-graphics decoder 6 decodes a presen- 
tation graphics stream read from the BD- ROM orthe HDD 2s 
17 into non-compression graphics, and writes the non- 
compression graphics onto the presentation graphics 
plane 10. The decoding of the graphics stream results in 
a subtitle appearing on the screen. 

[0079] The presentation graphics plane 1 0 is a mem- 30 
ory area having the size of one screen, and is able to 
store non-compression graphics of one screen. The res- 
olution of the presentation graphics plane 10 is 
1 920X 1 060. Each pixel of the non-compression graphics 
stored in the presentation graphfcs piane 1 0 is represent- 35 
edbyane-bitindex color. The non-compression graphics 
stored in Sie presentation gr^hics plane 10 are dis- 
played after the index color is converted using a GLUT 
(Color Lookup Table). 

[OOSO] The combining unit 1 1 combines the non-com- 
pression picture data (i) with the data stoned in the pres- 
entetion graphics plane 10. 

[0081] The font generator 12 expands the text code, 
which is contained in the text ST stream, into bit maps 
using character fonts. 4S 
[0082] The l-graphics decoder 13 decodes an interac- 
tive graphics stream, which is read from the BD-ROM or 
the HDDt7, into non-compression graphics, and writes 
the non-compression graphics onto the interactive 
graphics pSane 1 5. so 
[0083] The switch 1 4 selectively writes, onto the pres; 
entation graphics plane 10, eitherthefontsequence gen- 
erated by the font generator 1 2 or the graphics obtained 
as a result of the decoding by the P-graphics decoder 9. 
[0084] The interactive graphtes plane 15 stores the ss 
non-compression graphics that are obtained as a result 
of the decoding by the !-graphics decoder 13. 
[0085] The combining unit 1 6 combines the datastored 
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in the interactive graphics plane 1 0 with a composite irri-. 
age (a combination of the non-compression picture data 
and the data stored in the presentation graphics plane 
7} output form the combining unit 8. 
[0086] The HDD 1 7 is an internal medium that stores 
therein SubClips, Clip information, and PlayListinfonna- 
tion downloaded via a network or the !ike. This PlayList 
information in the HOD 17 differs in that it can specify 
Clip infomnation whether the C!ip infomiation exists on 
the BD-ROM or in the HDD 17. For this specification, the 
PlayList information in the HDD 1 7 need not specify a 
file on the BD-ROfvl by a full path. This is because the 
playback apparatus recognizes the HDD 1 7 togetherwiUi 
the BD-ROM as one virtual driver (called a virtual pack- 
age). Therefore, with a five-digit value, which is a file 
body of a fi!e storing Clip inSomriation, specified therein, 
the CSip_lnformation_file_name is the Playltem informa- 
tion and the Clip_)nfoTmationJi!e_name in the SubPlay- 
item information are used to specify an AVClip on the 
HOD 17 orthe BD-ROM. Reading data stored in the HDD, 
and combining this dynamically with the data stored in 
the BD-ROM can produce various playback patterns. 
[0087J The read buffer 18 is a FSFO memory, and 
stores TS packets read from the HDD 17 in a Rrst-ln- 
First-Out manner. 

[0088] The demultiplexer (De-MUX) 19 extracts TS 
packets from the read buffer 18, and converts the TS 
packets into PES packets. The demultipiexer 1 9 outputs, 
out of the PES packets obtained by ttie conversion, PES 
packets that have desired streamPIDs, to the font gen- 
erator 12. 

[0089] The audio decoder 20 decodes PES packets 
output from the demuitiplexer 1 9, and outputs ttie audio 
data in the non-ccwnpression fonmat. 
[0090] The scenaio memory 21 stores the current PL 
Information and the cument Clip inforniation. The current 
PL information is a piece of PL information that is a current 
taipet of processing, among a plurality of pieces of PL 
information recorded on the BD-ROM. The current Clip 
Information is a pieceofa Ciipinfomiationthatis acun-ent 
target of processing, among a plurality of pieces of Clip 
information recorded on the BD-ROM. 
[0091] The CPU 22 executes «ie software stored in 
the instruction ROM 24 and controls the entire playback 
apparatus. 

[0032] The key event processing 23 outputs key 
events for perfonning operations in response to key op- 
erations with respect to the remote controllerorthe front 
panel of the playback apparatus. 
[0093] The instruction ROM 24 stones software that 
defines the control by the playback apparatus. 
[0094] The switch 25 is used to selectively enter data, 
which has been read from the BD-ROM or the HDD 1 7, 
into any of the read buffer 2, the read buffer 18, the sce- 
nario memory 21, and the local memory 29. 
[0095] The GLUT unit 26 converts the index coior of 
the non -compression graphics stored in the video plane 
5, into the Y, Cr, and Cb values. 
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[0096] The GLUT unit 27 converts the index color of 
the non-compression graphics stored in the interactive 
graphics plane 15, into the Y, CR, and Cb values. 
[00971 The PSR set 28 is a register embedded in the 
playbao1< apparatus, and is composed of 64 PiayerStatus 
Registers (PSR) and 4,096 General Purpose Registers 
(GPR). Among the values set in the Player Status Reg- 
isters (the set values are referred to as PSRs), PSR4 to 
PSR8 are used to represent a cun-ent playback position. 
[0096] The PSR 4 is set to a value ranging from 1 to 
1tX> to indicate a Title to which the cun'ent piayback po- 
sition belongs, and Is set to a value 0 to indicate that the 
curfent playback position belongs to the top menu, 
[0099] PSRS is set to a value ranging from 1 to 999 to 
indicate a Chapter number of aChapter So whichthecur- 
rent playback position belongs, and Is set to a value Ox- 
FFFF to indicate that Chapter numbers are invalid in the 
playback apparatus. 

[01 00] PSR6 is set to a value ranging from 0 to 999 to 
Indicate a PL number of a PL (current PL) to which the 
current playback position bebngs. 
[01 01 ] PSR7 is set to a value ranging from 0 to 255 to 
indicate a Playltem number of a Playltem (current Play- 
Item) to which the current playback position belongs. 
[0102] PSRS is set to a value ranging from 0 to Ox- 
FFFFFFFFto indicate the currentplayback position (cur- 
rent PTM (Presentation TiMe)) using the temporal accu- 
racy of 45 KHz. With the above-desaibed PSR4 to PSRS, 
it Is possible to identify the cun-ent playback position. 
[0103] The local memory 29 is a cache memory for 
temporarily storing the data recorded on the BD-ROM so 
as to cover the slowness in reading data from the BD- 
ROM. Due to the presence of the local memory 29, ap- 
plications are executed efficiently in BD-J mode, FIG. 
1 7A shows how Java archive files stored on the BD-ROM 
are identified in the local memory 29. In the table In FIG. 
17A, the left-hand column shows the file names on the 
BD-ROM, and the right-hand column shows the file 
names in the local memory 29, A comparison of the left- 
hand column and the right-hand column shows that the 
files in the local memory 29 are specified with a file path 
from which the directory specification 'BDJA" has been 
omitted. 

[0104] FIG. 1 78 shows application of FIG. 1 7A. In this 
application example, data stored in the file consists of a 
header and data. The file path in the local memory 29 is 
used as the header, As shown in FIG. 17B, using the 
partially-abbreviated file path on the BD-ROM as the file 
pa^ enables the file path to be stored in the header, and 
therefore the location of the data on the BD-ROM Is ob- 
vious. 

[0105] TTiis completes the h^ware structure of the 
playback apparatus of the present embodiment. The fol- 
lowring describes the software structure of the playback 
apparatus of the present embodiment. 
[0106] FIG. 18 shows, in the layer structure, the hard- 
ware and the software stored in the ROM 24. As shovm 
in FIG. 18. the layer structure of the playback apparatus 
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is composed of thefollowinga), b),c), d-1), d-2), e), andf). 

a) The logical hardware layer; and, thereon. 
s tv/o layers that are: 

b) a presentation engine 31 that controls playback 
by AVCIlps: 

c) a playback control engine 32 that performs play- 
back control based on PlayUst information and Clip 
Infomnation. 

On the top layer is: 

e) a module manager 34 that executes branching 
between Titles. 

[01 07] On a same layer between a HO M V module 33 
and a module manager 34 are: 

d-1) »ie HDMV module 3 3 that decodes and exe- 
cutes movie objet^; and 

d-2) a BD-J module 35 that decodes and executes 

BD-J objects. 

[0108] The BD-J module 35 is What is called a Java 
platfoim, having a construction centering on a Java vir- 
tual machine 38 that includes a work memory 37, and is 
composed of an appiication manager36, an event listner 
manager 39, and a default operation manager 40. First, 
the presentation engine 31 to the module manager 34 
are described. FIG. 19 is an iilustration of the processes 
perfomned by the presentation engine 31 to the module 
manager 34. 

[0109] The presentation engine 31 executes AV play- 
back functions. The AV playback functions in the play- 
back apparatus are a group of traditional functions suc- 
ceeded from CD and DVD players. The AV playback 
functions include: Play, Stop, Pause On, Pause Off, Still 
Off, Forward Play (with specification of the speed), Back- 
ward Play (with specificaUon of the speed). Audio 
Change, Subtitle Change, and Angle Change. To realize 
the AV playback functions, the presentation engine 31 
conft-crfs the video decoder 4, the P-graphics decoder 6, 
the l-graphics decoder 13, and the audio decoders© so 
as to decode a portion of the AVCiip, which has been 
read to the readbuffer2, corresponding to a desired time. 
Here, the desired time maybe the time specified by PSRS 
(current PTM). With this constaiction, it is'possible to play 
a portion of an AVClip that corresponds to an arbitrary 
time. The sign @1 in FIG. 19 indicates the start of de- 
coding by the presentation engine 31. 
[0110J The playbackcontrol engine (PCE) 32-performs 
functions Siat include; (i) PlayList playback control htnc- 
tions; and (ii) status obtaining/sening function for obtain- 
ing and setting statuses in the playback apparafeis. The 
PlayList piayback control functions Is, among the AV 



EP 1 672 637 A1 



T5 



SO 



45 



12 



21 



EP 1 672 637 A1 



22 



playback functions performed by the presentation engine 
31 , a playbacl< start, a playback stop orthe like that are 
performed based on the current PL infomiatbn and Clip 
informatior!. The functions (i) and {ii) are performed in 
response to the function calls that are issued by the HD- s 
MV module 33, the module manager 34 and the BD-J 
module 35. That is to say, the playback control engine 
32 executes its own functions in response to instructions 
made by user operations and instmctions from the upper 
layer in ttie layer model, m FIG. 1 9. the arrows with the lo 
signs ®2 and ®3 indicate the playback control engine 
32 referencing the Clip infonnation and the PlayLlst In- 
fonmation. 

£0111] The HDMV module 33 is 8 main body for exe- 
cution in movie mode. If notified by the module manager '5 
34 of a Movie Object that constitutes a branch destina- 
tion, the HDiVI V module 33 reads, from the tocal memory 
29, the Movie Object that constitutes the branch desti- 
nation, decodes the navigation ccmmand written in the 
Movie Object, and issues, based on the decoding results, so 
a function call to the playback control engine 32. In FIG. 
19, the arrows with signs V2, V3, and V4 respectively 
indicate the following: receiving notification of the branch 
destination Movie Object from the module manager 34 
(V2); decoding the navigation command written in the 
Movie Object (V3); and issuing a function call to the play- 
back control engine 32 (V 4). 

[01 1 2J The module manager 34 holds the IndexTable 
that is read from the BD-ROM, and perfonns a branch 
control. The branch control includes receiving a Title so 
number that is a jump destination when the HDMV mod- 
ule 33 has executed a JumpTitle command or when the 
BD-J module 35 has issued aTitle jump API, andnotifying 
the Movie Object orthe BD-J Object that composes the 
Title to the HDMV module 33 or the BD-J module 35. In 35 
FIG. 19, the arrows With signs VO. VI, and V2 respec- 
tively indicate the following: executing a JumpTitls com- 
mand (VO); the module manager 34 referring to the In- 
dexTable (VI); and sending notification to run a Movie 
Object that is the branch destination {V2). 
[0113] Tliis completes the description of the presenta- 
tion engine 31 to the module manager 34. The following 
describes the appiication manager 36 with reference to 
FIG. 20, FIG. 20 shows the appiicaUon manager 36. 
[0114] TTie application manager36 executes run con- 
trol of an application by referring to the application man- 
agement table, and control to temninate a Title normally, 
[01 15] The run control includes, each time notification 
of a BD-J object that is a branch destination is received 
from the module manager 34, reading that BD-J object, no 
refem'ng to the application ma n agement table in the BD' 
J object, and accessing the local memoty 29. Run control 
also includes reading, to the work memory, the xlet pro- 
gram that constitutes the application that has a life cycle 
at the current playback position. In FIG. 20, the signs iri, ss 
fc2, and fr3 respectively indicate the follov/ing: notifica- 
tion of the branch destination BD-J object in run qontrol 
(*!); referring to the application management table 



(i^2); and instructing the Java virtual machine 38 to run 
an application. With this instmctlon to run an application, 
the Java virtual machine 38 reads the xlet program from 
the local memory 29 onto the wori< memory 37 (;^5). 
[0116] Temnination control of a Title includes control 
when the Title tenminates normally and control when tiie 
Title terminates abnormally. The controi when the Title 
terminates nomialiy is contro! for, when a jump Title API 
has been called by an application that constitutes a Title, 
issuing a request to the main body of branch contro! (the 
module manager 34) to switch to the branch destination. 
The anrow with the sign A6 indicates notification to the 
module manager34 in termination control. When the TItfe 
terminates nomially, the application that constitutes Ihe 
Title may remain running. This is because a judgment of 
whether or no! to terminate the application is made in the 
destination branch Title. Although nottouchedonindetail 
in the present embodiment, the application manager 36 
perfomis processing to read a Java archive file from the 
BD-ROM into the local memory 29 (rt8). The sign iiB 
indicates this reading into the local memory 29. 
[0117] This completes the description of the applica- 
tion manager 36. TTie following describes the work mem- 
ory 37 to the default manager 40 with reference to FIG. 
21. 

[0118] The work memoty 37 is a heap area in which 
is located xlet programs that constitute applications. Al- 
though the work memory 37 is actually located in the 
Java virtual machine 38, the work memory 37 is shown 
on a higher iayerthan the Java virtual machine 38 in the 
drawing for convenience. The xlet programs in the work 
memory 37 include EvenlListner and JMF player in- 

[0119] The Java virtual machine 38 loads the xlet pro- 
gram that constitutes an application onto the work mem- 
ory 37, decodes the xlet program, and executes process- 
ing based on the decoding results. As described, the xlet 
program includes a method to instruct generation of a 
JMF player instance and a method to instruct execution 
of this JMF player instance, and therefore, perfonns con- 
trol with respect to the lower layers to implement the 
processing instmcted by the methods. If JMF player in- 
stance generation is instructed, the Java virtual machine 
38 obtains the JMF player instance associated with the 
YYYY.MPLS file on the BD-ROM. Further, if execution 
of the JMF method in the JMF player instance is instruct- 
ed, the Java wrtual machine 38 issues a JMF method to 
a BD middleware so that a function call corresponding 
to the BD playback apparatus replaces the existent func- 
tion call, and issues the function call after replacement 
to the playback control engine 32. 
[0120] The event listner manager 39 analyzes the key 
events and distributes the events. The solid line arrows 
01 and <>2 in FiG. 21 indicate distribution of events by 
the event listnermanager39. If the event to be distributed 
is a key event that has been registered in the xlet pro- 
gram, such as START, STOP, or SPEED, the event list- 
ner manager 39 dist^butes the event to an xlet program 
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that is being indirectly referred to by the BD-J Object. 
START, STOP, and SPEED are events corresponding 
to JMF, and these key events are registered therewith in 
the Event Liatner in the xlet program. Therefore, the xlet 
program can be run according to ttiese key events, if the 
event to be distributed is a key event that has not been 
registered with the Event Listner, the event llstner man- 
ager 39 distributes th e event to the delault operation man- 
ager 40. Various liey events, including audio switch and 
angle switch, that are not registered with Event Listner 
may occur in the BD-ROM playback apparatus, therefore 
the above-described arrangement is provided so as to 
process each key event wifliout fail. 
[0121] When a key event that is not registered with 
Event Listner in the xlet progrsm is distributed to the de- 
fault operation manager 40 by the event listner manager 
39, the default operation manager40 issues to the play- 
back control engine 32 a function call that corresponds 
to the event that is not registered with Event Listner. The 
arrow 03 in FIG. 21 indicates the function call issued by 
the default operation manager 40. Mhough the events 
that are not registered witti Event Listner are distributed 
by the event listner manager 39 and the default operation 
manager 40 in FIG. 21, the playback contrd engine 32 
may directly receive the events thai are not registered 
with the Event Listner, and peiform playback control (O 
4 in FIG. 21). 

(Description of Fiowdiarts) 

[0122] The atxjve deso-iption of the application man- 
ager 36 is only an outline thereof, The processes of the 
application manager 36 are shown in detail in FIGs. 22 
and 23. The following describes the processing proce- 
dures of the application manager 36 in more detail v/ith 
reference to the (iowcharUs. 

[0123] FIG. 22 is a flowchart showing control proce- 
dures of file application msmager 36 for branching. The 
processing shown in ttiis flowchart Is for running or ter- 
minating an application (refen-ed to as applk;ation x) that 
fulfills the conditions of step S2 to step S5. 
[0124] At step S2 the application manager 36 judges 
v/hether or not an application x exists that is not run in 
ttie branch destination Trtle, but lives in the branch des- 
tination Title and whose run attribute in the branch des- 
fination Title is AutoRun, and if such an application x ex- 
ists, cache sense Is performed witti respect to the local 
memory 29. If, as a result of the cache sense, the appli- 
cation X is In the local memory 29 (YES at step S7), the 
application x is read from the local memory 29 into the 
worit memory 37 (step SB). If an plication x is not in 
ttie local memory 29, the Explication manager 36 reads 
an application x from the BD-ROM to the focal memory 
29, and then reads the application x from the local mem- 
ofy 29 to the work memory 37 (step S9). 
[0125] At step S3, the application manager 36 judges 
whether or not an application x exists that is Ijeln^ run in 
the branch origin Trtle does not live in the branch desti- 
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nation Title. If such an application x exists, the applicatiori 
X is deleted from the work memory 37 and tenmlnated 
{steps 10). 

[0126] At Step S4, the applk:ation manager 36 judges 
s whether or not an application exists that is Suspend in 
the branch origin, andAutoRun or Persistent in the 
branchdestination. If such an application exists, the ap- 
plication X is resumed (step Si 1 ). 
[0127] At step S5, the application manager 36 judges 
>D whether or not an application exists that is being run in 
the branch origin Title and is Suspend in the branch des- 
tination. If such an application exits, the application x is 
suspended (st^ 812). 

[0128] The processing forthe application manager36 
'5 to tenninate appik^ations is as shown in FIG, 23. FIG. 23 
is a flowchart showing the processing procedure for ter- 
minating ^plications. FIG. 23 includes loop processing 
in whteh step SI 6 to step S20 are repeatedly performed 
for each of the plurality of applications that are to be ter- 
20 minated {step Si 5). In Ihis loop processing, the applica- 
tion manager 36 issues a temiinate event so as to termi- 
nate an application that is running (step Si 6), sets a timer 
(step SI 7), and moves to loop processing composed of 
step SI 8 to step 820. If Event Listner receives this ter- 
minate event, the corresponding xlet program mns a ter- 
mination process. When the tetminalion process has 
ended, the xiet program is discardedfrom the work mem- 
ory 37, and terminated. 

[0129] The timer continues to count down w^lie the 
30 loop processing at step SIS to step S20 continues. At 
step 31 8 in the loop processing, the application manager 

36 judges whether or not the issue dastinatio n application 
has tenmlnated, and if ttie issue destination af^lication 
has not terminated, processing of application is terminat- 

35 ed. At step SI 9. the application manager 36 detennines 
whetherornotthetimerhas timed out, and if so, the issue 
destination application is deleted from the work memory 

37 ai step 320, so astofoncedlytermtnate the application. 
[0130] The processing by the above module manager 

10 34 is described wim reference to FIG. 24. 

[0131] FIG, 24 indioateE the process for terminating 
applications, in FIG. 24, the first row shows the applica- 
tion manager 36, and the second row shows three appli- 
cations. In the second row in FIG. 24, the application on 

IS the ieft-hand side shows an application that received a 
terminate event, and was successful in the temnination 
process. The middle application in the three applications 
in the second row of FIG. 24 is an application that re- 
ceived a terminate event, but failed in the temiinafion 

so process. The appiication on the right-handside is notpro- 

• * videdwithanEventListner, and therefore was unable to 
receive the terminate event 

[0132] The arrows epi and ep2 between the first row 
and the second row indicate issuing of tenvmiie events 
by the app licaSon manager, and the arrow ep3 indicates 
running a terminatiwi process. 
[0133] The third row is the status after status change 
when the tennination process succeeds, and Oils appli- 
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cation teminates according to its own termination 
processing. As with these xiet programs, ]f there are any 
applications that have not terminated within a predeter- 
mined period of lime, the application manager36forcedly 
removes them from the work memory 37. Specifying the 5 
forced termination of the fourth rov/ can also be said to 
be one of the missions of the appltcafion manager 36. 
[0134] As described above, according to the present 
embodiment, appitcationsSiat are run in the branch origin 
Title and do not live in the brandi destination Title are 'o 
automatically temiinated. Therefore, even if the progres- 
sion of playback is complicated due to conditional 
branching, the number of applications launched will not 
be such that the limit of the resources of the playback 
apparatus is exceeded. Since the running of applications '5 
beforeandafterbranchingcan be guaranteed, numerous 
disc contents \n which applications are executed while a 
digital stream is played are able be distributed. 

(Second Embodiment) 20 

[0135] VWereas the life cycle of the applications 
matches the Title time axis in the first embodiment, the 
second embodiment proposes part of the PL time axis 
as the life cycle of an application. Part of Uie PL time axis 25 
is expressed by Chapters, and therefore the life cycle of 
applications can be specified by writing a start point and 
an end point in terms of Chapters. FiG. 25A shows an 
a^)plication management table that defines life cycles on 
the PL time axis. There are three applications written in so 
the application management table in FIG. 25A, of which 
applioation#2 has a life cycle specified as Chapter#2 to 
.Ch^ter#3 of Title#1, and has an run attribute specified 
as AutoRun. Therefore, as shown in FIG. 25B, appiica- 
tion#2 is run at the start point of Chapter#2 and temiinat- ss 
ed at the end point of Chapter #3. 
[0136] On the other hand, Chapter#4 to Chatper#6 of 
TitleSi is specified as the life cycle of application#3. 
Therefore, as shown in FIG. 25B, application#3 Is tun at 
the start point of Chapter#4 and temilnated at tiie end 
point of ChapterifS. 

[0137] Because it performs processing based on the 
application management table written in this way, eadi 
time a chapter start point specified by a PLmark is 
reached, the application manager 36 of the present em- 'is 
bodiment judges whether or not any application exists 
whose life cycle starts at the chapter stan point, and if 
any such application exists, the application manager 36 
loads that application into the work memory 37. 
10138] Similarly, each time a chapter start point is 5" 
reached, the application manager 36 judges whether or 
not any appiication exists whose life cycle ends with the 
directly preceding chapter, and if any such ^plication 
exists, discards that application fran the work memory 
37. ss 
[0139] By managing the life of applications in units of 
chapters, the life cycles of applications can be specified 
even more precisely. However, it must be kept in mind 



that with disc content, retrograde along the time axis .is 
posstole. Retrograde is advancement in the opposite di- 
rection to the time axis because of rewinding. Repeated 
retrograde and advancement at chapter boundaries cre- 
ates an excessive load for reading because applications 
are loaded into and discarded from the work memory 
many Jimes. In view of this, in the present embodiment, 
the timing at which an application is run is the Instant that 
normal playback by the playback control engine 32 com- 
mences when having entered a Title. Here, PL playback 
includes nonnal plajfeack and trick playback. Trick play- 
back includes Forward Play, Backward Play, SkpNext 
and SkipBack. Applications are not run while Forward 
Play, Backward Play, Skipnext and SkipBack are being 
perfonned, and run when nonrsal playback has started. 
By using the moment at which normal play starts as the 
basis, applications are not repeatedly run more than nec- 
essary even if playback goes back and forth across a Nfe 
cycle. fvJote that processing that uses the i nstant of nonn al 
playback starting as a basis to rwn applications may also 
be exe«jled In cases in which the !ife cycle corresponds 
to a Title. 

[0140] As has been described, the present embodi- 
ment enables tJie life cyde of applications to be specified 
in units of chapters, which are smaller than PLsi and 
therefore applications can be controlled precisely. 

(Second Embodiment Modification Example) 

[0141] A priority level is given to each application in 
FIGs. 25A and 258. The priority level takes values of 0 
to 255. When there is competition between applications 
foruse of resources, the application managerSecan use 
the priority levels to decide which application to terminate 
forcibly, or which application to regain resources from. 
In the exarr^le in FIGs. 25A and 25B, the priority level 
of applk:^tion#1 is 255, and the priority level of each of 
application#2 and application#3 Is 1 28. Therefore, when 
there is competition between application*! and af^jlica- 
tion#2, the application manager 36 performs processing 
to forcedly terminate applicationS2, which has the lower 
priority level. 

(Thind Embodiment) 

[0142] Disc contents provided from a BD-ROM are 
composed of a plurality of Titles that are able to branch 
between each other. In addition to Titles that are consti- 
tuted from at least one PL and a control procedure that 
uses the PL, there are also non-AV Titles that are con- 
stituted from only aconfrol procedure forperfonningcon- 
trol with respect to the playback apparatus. These non- 
AV Titles are desa^ed in the present embodiment 
[01 43] There is an issue of how to set a Trtle time axis 
in non-AV Titles. FIG. 26A shows a Title time axis set 
based on a PL time axis. In this case, the PL time axis 
is used as the Title time axis, and life cycle of the appli- 
cation is set on this Title time axis. If there is no PL time 
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axis to use as a basis for the Title time axis, tlie Title time 
axis should be set as shown in FiGs. 26B and 26C. 
[01 44] FIG. 26B shows the Title time axis set based 
on the life cycle of a main application. The main applica- 
tion is the only application that has a run attribute set to 
AutoRun in the Title and is automatically run when the 
Title starts. One example of the main application is a 
launcher application. The launcher application is an ap- 
plication program that runs other applications. 
[0145J The concept behind FIG. 26B is that the Title 
time axis will continue as long as the main application is 
running, and the lime axis will end If the main applicafion 
temnlnates. FIG. 26C shows a Title time axis set based 
on the life cycles of a plurality of applications. Although 
only one application is njn at the start point of the Title, 
there are cases In which call processing is repeated by 
Ms application calling another ^plication, which in turn 
calls anoUier application. In this case, the Title time axis 
is considered to continue as long as one of the applica- 
tions is running, and that the Title time axis will end if a 
state of no application running is arrived at. if the Title 
time axis of a non-AV Title is set in this way, processing 
to branch to a predetermined Title can be perfonned si- 
multaneously with the end of the Title time axis uniformly 
regardless of whether the Title is an AV Ti«e or a non- 
AV Title. Note that the Title time axis in a non-AV Title is 
simply an imaginary time axis assumed in contrast to an 
AV Title, Therefore, the playback apparatus is un^le to 
reverse non-AV Titles on the Title time axis, or cue non- 
AV Titles to an arbitrary position on the Title tfrne aws. 
[0146] The above is an improvement wifii respect to a 
recording medium in the present embodiment. The fol- 
lowing describes an improvement with respect to a play- 
back apparatus of the present embodiment. 
[0147] The application manager36 of the third embod- 
ment performs processing such as shown in FIG. 27 in 
orderto end Trtles using the above procedure. This flow- 
chart has a loop structure in which steps S21 to step S23 
are repeated during Title playback. 
[0148] At step S21 , the application manager 36 judges 
whether or not a Title jump API has been called, and If 
so,makesa request to themodulemanager 34 to branch 
to a jump destination Title (step S27). 
[0149] Atstep S22, the applicationmanager36 judges 
whether or not a main application exists that may call an 
application In the Title, and if sudi a main application 
exists, diecks whether or not the main appfication is run- 
ning (step S25}. If the main application is not mnning, 
the application manager 36 interprets this as being the 
end of the Title, and notifies the module manager34that 
the Title has ended (step S26). 
[01 50] Step S23 Is executed if there is no main appli- 
cation (NO atstep S22}. Atstep S23, the application man- 
ager 36 judges whether or not there are no applications 
are runn ing. As above , if none are running, the application 
manager 36 interprets this as being the end of the Title, 
and notifies the module manager 34 that the Title has 
ended (step S26). 
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[0151] As has been described, with the present em- 
bodiment, it is possible even with a Title that does not 
involve PL playback to branch after execution of appii- 
cations is terminated, rather than branching while appli- 

s cations are being executed. 

(Fourth Embodiment) 

[01 52] The present embodiment reiates to an improve- 

10 ment that realizes menu control similar to that of a DVD, 
on a BD-ROM. FIG. 28A shows a menu hierarchy real- 
ized on a BD-ROM. The menu hierarchy In FIG. 28A is 
structured such that a TopMenu is provided on a highest 
layer, and the subordinate TltleMenu, SubTitleMenu.'and 

T£ Audiofi/lenu can be selected from the TopMenu. The ar- 
rows swi, sw2, and sw3 in FIG. 28A indicate switching 
between menus according to button selection. The Top- 
Menu is a menu in which buttons (sm , sn2, and 5n3 in 
the FIG. 28A) are provided for receiving a designation of 

20 any of audio selection, subtitle selection orTitle selection. 
[0153] The TltleMenu is a menu in which buttons are 
provided for receiving a selection of a movie theater ver- 
sion of a movie (Title), a director's cut of the movie, a 
game version, or the like. The AudioMenu is a menu in 

25 which buttons are provided for receiving a designation 
of whether audio playback should be in Japanese or in 
English. The SubTitieMenu is a menu in which buttons 
are provided for receiving a designation of whether sub- 
titles should be di^layed in Japanese or In English. 

30 [0154] FIG. 28B shows a MOVIE object for running the 
menus having this hieranshy, in FiG. 2BB, a FirstPlay 
OBJ, a TopMenu OBJ, an AudioMenu OBJ, and a Sub- 
TitieMenu OBJ are stored in MovieObject.tidmv, 
[0155] The RrstPlay Object (FirstPlay OBJ) is a dy- 

35 namio scenario that is automatically executed when the 
BD-ROM is loaded into the playback apparatus. 
[0156] The TopMenu Object (TopMenu OBJ) is a dy- 
namic scenario that controls behavior of the TopMenu. 
It is this TopMenu Object that is called when the user 

40 requests a menu call. The TopMenu object includes com- 
mands for changing the state of the buttons in the Top- 
Menu in response to operations from the user, and 
branch commands for branching in response to confir- 
mation ope rations with respect tothebuttons.The branch 

IS commands realize menu switches from the TopMisnu to 
the TitleMenu, the TopMenu to the SubTitieMenu, and 
the TopMenu to the AudioMenu. 
[0157] The AudioMenu object (AudioMenu OBJ) is a 
dynamic scenario that controls behavior of the Audi- 

so oMenu, and includes commands for changing the state 
... of buttons in the AudioMenu in response to operations 
from the user, and commands for updating audio settings 
in response to confirmation operations with respect to 
the buttons. 

55 [0158] The SubTrtleMenu object (SubTitieMenu OBJ) 
is a dynamic scenario that controls behavior of the Sub- 
TtieMenu, and includes commands for changing the 
state of the buttons In the SubTitieMenu in response to 
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user operations, and commands for updating PSR sub- 
titie settings in response to confirmation operations with 
respect to the buttons. 

[0159] The TstleMenu object fTstleMenu OBJ) is a dy- 
namic scenario that controls behavior of the TlSleMenu, s 
and includes commands for changing the state of the 
buttons in the TitleMenu, and branch commands for 
branching in response to confimiation (derations with 
respect to the buttons. 

[01 60] These menu-use MOViE objects realize menu w 
behavior such as that realized with DVDs. This completes 
the description of the MOVIE objects relating to menu 
control. 

[0161] FIG. 29 Illustrates an Index Table, and branch- 
ing from the Index Table to.Movte objects. The left-hand 'S 
side of FIG. 29 shows the internal structure of the Index 
T^le. The Index Table in the present embodiment in- 
cludes RrstPlaylNDEX, TopMenuiNDEX, AudioMenu- 
JNDEX, SubTitleMenulNDEX, TitleMenulNOEX, Tnie#1 
to<fmlNDEX,Title#m+1 to#n!NDEX, andTrtlettOlNDEX. so 
The an-ows bet and bc2 in FIG. 29 indicate a branch from 
the Index Table to the FirstPlayOBJ and a branch from 
the RrstPlayOBJ to the TopMenu, and the arrows bc3. 
bc4, and bc5 indicate branches from theTopMenu to the 
TItleMenu, the SubTttleMenu, and the AudioMenu. The 
arrows bc6, bc7, and bc8 Indicate branches from the Ti- 
tIeMenu to Movie objects. 

[0162J The FirstPlaylNOEX, TopMenuiNDEX, Audi- 
oMenulNDEX, SubTitleMenulNDEX, and TrtleMenulN- 
DEX are indexes for the FirstPlayOBJ, TopMenuOBJ, 30 
AudioMenuOBJ,SubTitlsMenuOBJ,andTitleMenuOBJ, 
respectively, whose identifiers are written in the indexes. 
[0163] TheTit!e#l to#mlNDEXare Indexes of the Title 
that are the first to the m-th entries on the BD-ROM . Writ- 
ten in these Indexes are re^eeUve IdenCfiers (IDs) of 3S 
MOVi E objects that are branch destinations when a Titie 
number Is selected from among 1 to m. 
[0164] The Titie#m+1 to #nlMDEX are Indexes of the 
Titles that are the m+1 to n-th entries on the BD-ROM. 
Written in these Indexes are respective identifiers (IDs) io 
of BD-J objects that are branch destinations when a Title 
number is selected from among m+1 to n. 
[0165] The Tttie#0 INDEX is an index that specffies a 
^5ovie object or a B D- J object that is a branch destrnaUon 
when a BD-J object is forcedly temninated. Inthe present is 
embodiment, the identifier of the TopMenuOBJ is stored 
in this TitletfO INDEX. 

[0166] FIG. 30A shows branching w^en the IndexTa- 
ble is written as shown in FIG. 23. Since tiie Index Table 
is written in this way, when a branch command is exe- so 
cuted for which the branch destination Is any of labels 
Titlefl to TitleSm, the identifier of the corresponding one ' ' 
of Movie objects #1 to #m is extracted from the corre- 
sponding one of Titleffl Index to Tit!s#m Index. When a 
branch command is executed for which the branch des- 55 
tinatton is any of labels TftleffoH-l toTitle#n, the identifier 
of the corresponding one of Movie objects #m+1 to #n is 
extracted from the corresponding one of Title#m-i-1 Index 



to TrtleSnindex. The identifiers of the BD-J objects *fin+.1. 
to #n each have a 5-digit value that expresses the file 
name. Therefore, one of "00001. BD-J, 00002.BD-J, 
00003.BD-J.,,' is extracted, the dynamic scenario of this 
file name is read to the memory, and executed. This is 
branch processing using the Index Table. 
[0167] FIG. 308 shows branching v/hen a BD-J object 
that is being executed is forcedly terminated. In the 
branching when the BD-J object is forcedly terminated, 
the idenUfier is e«racted from the Title#Olndex, and she 
dynamic scenario of that identifier is executed by the play- 
bacV. apparatus. If this identifier is the identifier of the top 
menu Titie, the top menu OBJ is automatically selected 
whe n the application is forcedly tennin ated. 
[0168] The above is an improvement relating to a re- 
cording medium of the present embodiment The follow- 
ing describes an improvement relating to a playback ap- 
paratus of the present embodiment. The module man- 
ager 34 in the playback apparatus perfonms processing 
according to procedure shown in FIG, 31, to respond to 
the described improvement in the recording medium. 
FIG. 31 is a flowchart showing the procedure for process- 
ing by the module manager 34. The flowchart includes 
loop processing that is composedof step S31 and step 
S32, and corresponding processing is executed is the 
case of "YES" at either step S31 or step 332. 
[0169] At step S31. the module manager 34 judges 
whether or not there has been a call for a Title jump API, 
and if there has been a call for a Titie jump API, obtains 
a Title number j which is the branch destination label 
(step S33), extracts IDj from the Index of the Title number 
j in the Index Table (step S34), and causes the HDMV 
module 33 or the BD-J module 35 to execute the Movie 
Object or the BD-J object of the IDj (step S36). 
[0170] At step S32, the module manager 34 judges 
whether or not there has been notification of an end of a 
Title from the application manager 36. and if there has 
been such notification (YES at step S32), causes the 
HDMV module 33 or the module manager 34 to execute 
the TopMenuOBJ that constitutes the top menu Titie 
(step S36), 

[0171] The following describes an example of opera- 
tions when the application manager36forcedly termi- 
nates anapplicatlonas described above, with reference 
to FIG. 32. Here, ttie Trtle to be played is a non-AV Title 
thai includes a game application in which falling tiles are 
stacked upon each other. The lower row in FIG. 32 shows 
a Title time axis composed of the life cycle of the appli- 
cation, and the uf^er row shows ihe images displayed 
along the Title time axis. If the non-AV Title is a game 
application, a screen of ihe game application is displayed 
as shown on tiie left-hand side of the upper row in FIG, 
32 during the life cycle of the game application. If the 
game application terminates abnornially due to a bug, 
the application manager 36 forcedly terminates the game 
application in accordance with the flow chart in FIG. 23, 
and notifies the module manager 34 that the Title has 
ended. On being notified that the Title has ended, the 



17 



.1672637A1J.> 



31 



EP 1 672 637 Al 



module manager 34 branches to the top menu Title. This 
results in an image such as that on the right-hand side 
of ttie upper row in FIG. 32 being displayed, and an op- 
eration from the user is waited for, 
[0172] In this way, according to the present embodi- 
ment, control to branch to the top menu Trtle can be per- 
formed even when a non-AV Title that itvcludes a program 
but does not Include a digital stream ends. This avoids 
blackouts or hang-ups when an application tenninates 
due to an error. 

(Fifth Embodiment) 

[01 73] The present embodiment relates to an improve- 
ment in how synchronization with PL playback is realized 
in BD-J mode. When the Java virtual machine 38 de- 
codes a JMF player instance {A. piay;) that instructs play- 
back of the JMF pSayer instance in the example of FIG. 
68, the Java virtual machine 3B calls the PL playback 
API, and directly aftercalSing, relums a response showing 
•success', to the application. 

[0174] If the PL playback API is called, the Playback 
Control Engine 32 executes processing based on the PL 
information. If the PL has a plaj^ack time oJ two hours, 
the aforementioned processing continues for these two 
hours. The pnjblem here is that there is agap in the time 
at which the Java virtual machine 38 returns the success 
response and the time atwhich the playback control en- 
gine 3 2 actuaily tenminates the processing. Since the 
Java virtual machine 3B is an event-driven processing 
main body, it returns a response showing playback suc- 
cess orplaybad<failure directly afterthe call, but because 
the actual tenmination of processing bythe playback con- 
trol engine 32 is two hours later, if the time at which the 
success response is returned to the application is used 
as a basis, the completion of processing will be detected 
two hours later. !f forward play, backward play, or skip 
are perfomned during the PL playback, this playback time 
oi two hours will flucajate to be more or less than tv/o 
hours, and detection of the completion of processing will ■ 
be even more difficult. 

[01 75] The playback control engine 32 operates stand 
alone from the application, and therefore is unable to 
interpret the endof PL playback as being the end of She 
Title in ajudgment such as that in the third embodiment. ■ 
For this reason, in the present embodiment, regardless 
ofwhetherthe application has temiinatedornot. the play- 
back control engine 32 waits for a playback completion 
event as long as there Is a JMF player instance In the 
work memory 37, in other words, while the BD-J module i 
35 holds the right to control the presentation engine 3l'. 
Then when there is a playback completion event, the 
playback control engine 32 interprets this as the Title 
having ended, and issues notification to the module man- 
ager 34 to branch to the next Title. This procedure ena- ; 
bles playback control engine 32 to treatthepoint at which 
PL playback is compiete as the completion of the'Title. 
[0176] The following describes ftiespecificcontrot pro- 



cedure bythe playback control engine 32, with reference 
to the flowcharts in FIG. 33 to FIG. 37. 
[0177] FIG, 33 is a flowchart showing a PL playback 
procedure by the playback control engine 32. This play- 
back procedure mainiy includes control with respect to 
the presentation engine 31 {step S46), and control with 
respecttothe BD-ROM drive 1 orthe HOD 1 7 (stepS48). 
The Playltemthatisthe processingtargetinthisflowchart 
is called Playltem#x. The processing shown in this flow- 
' chart is reading of the current PL infonmation (,mpls) (step 
S41), and then executing processing of step S42 to step 
S50. Step S42 to step S50 constitute loop processing in 
which the processing of step S43 to step SSO is repeat- 
edly perfomied for each piece of PI information the con- 

■ stitutes the cument PL infomiation, until the result of step 
S49 is "YES". The Playitem that is the target processing 
in the loop processing is called Playltem#x (Pl#x). Play- 
ltem#x is initialized by being set as the head Playitem in 
the current PL (step S42). The requirement for ending 

' the aforementioned loop processing is that Playltem#x 
is the last Playitem of the current PL (step S49). If Play- 
ltem#x is not the last Playitem, the next Playitem in the 
current PL is set as Playltem#x (step 850). 
[0178] In step S43 ta step 550 that are repeatedly ex- 
ecuted in the loop processing, the playback control en- 
gine 32 reads ttie Clip Information specified by the Clip„ 
information„ftle_name of PlayltemSx to the scenario 
memory 21 (step S43), converts the Injime of Play- 
ltem#x to an I picture address u using the EP_map of the 
current Clip information (step S44), converts the Out_ 
time Playltemftx to an I picture address v using the EP„ 
map of the cun-ent CIp infomnation {step S45), finds the 
next I prcture afterthe address v obtained according to 
these conversions, and sets the address one before the 
found I picture as an address w {step S47). Then, using 
the calculated address w, the playback contro! engine 32 
instmcts the BD-ROIW drive 1 or the HDD 17 to read TS 
packets from the ! picture address u through to the ad- 
dress w (step S46). 

[0179] Meanwhile, the playback contro! engine 32 in- 
stmcts the presentation engine 31 to output the mark„ 
time_stamp of the current PLMark through to the Out_ 
time of Playltem#x (step S46). "Hie above step S45 to 
step S48 result in the part of the AVClip instructed ac- 
cording to Playltem#x being played. 
[0180] Next, the playback contro! engine 32 judges 
whether Playltem#x is the last PI of the current PL (step 
S49). 

[0181] If PlayltemSx is not the tast PI qf the cun-ent PL 
the playback control engine 32 sets the next Playitem in 

■ the current PL as Playltem#x (step S50), and returns to 
step S43. As a result of repeating step S43 to step SSO, 
the Pis that constitute the PL are successiveiy played. 
[0182] FIG. 34 is a flowchart showing an angle switch 
procedure and a Sk^Back and SkipNext procedure. The 
processing of this flowchart is perfonned in parallel with 
the processing of FIG. 33, and includes loop processing 
composed of step S51 to step S52 «ial is performed re- 
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peatedly. At step S5i in this loop, the playback control 
engine 32 judges whether or not Uiere has been a cafi 
Irom the Java virtual machine 38 for an API ttiat requests 

angle switching, and if there has been acall for an angle 
switching AP!, the playback control engine 32 executes 5 
an operation for switching the current Clip information. 
[0183] At step S55 of F!G. 34, the playback control 
engine 32 judges whetheror not is_multi_angles of Play- 
ltem<(x is ON. Here, is_multi_angles is a flag showing 
whetherornotPlayltem#x is multi-angle-compatible, and 'o 
if the result of step S55 is NO, moves to step S53. If the 
result of step S55 is YES, the playback control engine 
32 executes step S56 to step S59. At step S56 to step 
S59, the playback control engine 32 substitutes the angle 
number after switching into a variable y (step S56}, reads 
Clip information specified by She y-th Ciipjnformation^ 
file_riamein Piayltem#x to the scenario memory 21 (step 
S57), converts the current PTM to an I pictufe address 
u using the EP„map of tiie cuirent Clip infoimation (step 
S5B), and converts the Outjime of Playltem#x to an I ?o 
picture address v using the EP_map of the current Clip 
infonmation (step S59). After changing the I picture ad- 
dresses u and V in this way, the playback control engine 
32 moves to step S46. TS packets of another AVClip are 
read according to the move to step S46, and hence the 25 
contents of the video are switched. 
[0184] Meanwhile, at step S52 in the loop in FIG. 34, 
the playback control engine 32 judges whether or not 
there has been acall for an API signifying SkipBack/Skip- 
Next from the Java virtual machine 38, and if there has so 
been such a call, executes the processing of the flowchart 
of FIG. 35. FIG. 35 is a flowchart showing processing 
when a SkipBack or SkipNext AP! is called. There are a 
wide variety of ways In which SkipBack and SkipNext 
.can be executed. It should be noted that the description 35 
given here is simply one exsmple. 
[0185] Atstep S61 , the plajfeack control engine 32 ob- 
tains Ihe current Mark infomiation by converting the cur- 
rent PI number and the cun-ent PTM shown In the PSR. 
Atstep S62 the ptaybackcontroi engine 32 judges wheth- io 
er the key that was pressed is the SkipNext key or the 
SkipBack key. The playback control engine 32 sets a 
direction flag to +1 if the pressed key is the SkipNext key, 
and to -1 if the pressed key is the SkipBac* key. 
[0186] At step S65, the piaybat* control engine 32 « 
sets, as the number of the current PLMark, a numberthat 
is a total of the number of the current PLMark and the 
value of the direction flag. If the pressed key is the Skip- 
Next key, the direction flag is set to +1 , and therefore the 
current PUvlark is incremented. If the pressed key is the so 
SkipBack key. Ihe direction.fiag is set to -1 , and therefore 
the current PLMark is decremented. 
[0187] At step 866, the plaj^ack control engine 32 sets 
the PI written in the ref_to_Playlt«n„ld of the current 
PLMark, as PiayltemSx. and at step 867. reads flie Clip S5 
infomiation specified by the C!ip_infoniiatiofl_fi!e_name 
of Playltem#x. At step 868. the playback control engine 
32 converts the mark_time_stamp of the cun-ent F^LMark 



to an I picture address u using the EP_map of the current 
Clip infomnation. On the other hand, atstep S69,the play- 
back control engine 32 converts the Outjime of Play- 
ltem#x to an I picture address v using She EP_map of the 
current Clipinfon-nation. Atstep S70, the playback control 
engine 32 instructs the presentation engine 31 to output 
from the mark_time_stamp through to the Out_time of 
Playltem#x, and then moves step 847 of FIG. 33. As a 
result of changing the I picture addresses, u and v in this 
way, and moving to step S47 after instructing playback 
of anotherpart,TS packets from another AVCilp^read, 
thus realizing the switching of ttie video contents. 
[0188] FIG. 36 is a flowchart showing details of 
processing by the presentation engine 3 1 . This flowchart 
includes setiing of the PTS of the I picture in the current 
PTM (step 871), and subsequent execution of loop 
processing composed of step 372 to step S77. 
[0189] Next the loop processing in step S72 to step 
S77 is described. Tills loop processing repeats playback 
output of ptc^re and audio conresponding to the current 
PTM and updating of the current PTM. Step S76 in this 
loop processing specifies the requirement for ending the 
loop processing. In other Vrfords, step S76 specifies that 
the requirement for ending the loop processing is that 
the current PTM is the Outjime of Pi#x. 
[0190] Atstep 873, the presentation engine 31 judges 
whetherthere has been a call for a Forward Play API or 
a Backward Play API from the Java virtual machine 38. 
If there has been acall, the presentation engineSI judges 
at step 878 which of a Forward Play API and a Backward 
Play API the call is for, and if the call is for a Forward 
Play AP I, sets th e PTS of the n ext I pictu re as th e cu n-ent 
PTM (step 879). By setting the PTS of the next 1 picture 
as the current PTM is this way. the AVClip is playedjump- 
ing one secondat atmie. As a result, the AVClip isplayed 
fast in the forwan:! direction at double speed or the like. 
If the call is for a Backward Play API, the presentation 
engine 31 judges whether or not the current PTM has 
reached the Outjime of PlayltemSx (step seo). If Ihe 
Outjime has not been reached, the PTS of the directly 
preceding I picture is set as the current PTM (stepSSI), 
By setting the read-destination address Aas the preced- 
ing I pic^re in this way, the AVClip is played in the back- 
ward direction jumping one second at a time. As a result, 
the AVClip is played in the reverse direction at double 
speed or the like. Note that there are a wide variety of 
ways in which Forward Play and Backward Play can be 
executed. It should be noted that the description given 
here is simply one example. 

[0191] At step S74, the presentation engine 31 judges 
whether or r«>t a menu call API has been called, and if a 
menu call API has been called, suspends the present 
playback processing (step 882), and executes s menu 
program that is for menu processing (step SB3), Accord- 
ing to the above processing, if there is a menu call, the 
processing for menu display is executed after suspend- 
ing playback processing. 

[0192] At step S75, the presentation engine 31 judges 
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whether or not a SubPlayltem#y that specifies Play- 
ltem#x according to, a sync_Play!lemJd exists, and If 
so, moves to the flowchart of FiG. 37. FIG. 37 is a flow- 
chart showing a SubPlayitem plai4iacl<procedure. In this 
flowchart, the presentation engine 31 first judges at step 
S86 whether or not the current PTM is the sync_staft_ 
PTS_of jDlayltem of Sub Play Itetnify. If so, at step S93, 
the presentation engine 31 instructs the playback control 
e ngi n e 32 to perf orni p layback pnscessing based on Sub- 
Play!tem#y. 

[0193] Step S87 to step S92 Of FIG . 37 are a flowchart 
showing playback processing based on SubPlayltem#y. 
[0194] At step S87, the presentation engine 31 reads 
the Clip information specified by the Clipjnfomiation. 
file_name of the SubPlayitem#y. At step S86, the pres- 
entation engine 31 converts the ln_time of SubPlay- 
item#y to an address a using the EP_map of the current 
Clip inforn^ation. On the otherhand, atstep S89; the pres- 
entation engine 31 converts the Out_time of SubPiay- 
ltem#y to an address p using the EP_map of the current 
Clip information. At step S90, the presentation engine 31 
Instructs «ie decoder to output from me In.time of Sub- 
Piayltem#y to the Outjime of SubPlayltem#y. The pres- 
entation engine 31 finds the next I picture after the ad- 
dress p obtained by the conversions, and sets the ad- 
dress one before the found I picture as an addressy (step 
S91). The presentation engine 31 instructs the BD-ROM 
drive 1 or the HDD 1 7 to read the TS packets from the 
address a and the address y in SubClipSz using the ad- 
dress y calculated in this way (step S92). 
[0195] Returning to FIG. 33, the following describes 
processing by the playback control engine 32. At step 
S53, the playback control engine 32 judges whether or 
not playback control by the presentation engine 31 is 
complete, and the result of step S53 is "NO" as long as 
the processing of the flowchart of FIG. 36 is being per- 
formed with respect to the last Playltem#x. Once the 
processing of the flowchart of FIG. 36 has ended, the 
result of step S53 Is *YES", and the playback control en- 
gine 32 moves to step S54. At step S54, the playback 
control engine 32 outputs a playback completion event 
to the Java virtual machine 38. This output enables the 
Java virtual machine 38 to know that the playback time 
of hvo hours has elapsed. 

[0196] This completes the processing by the playback 
control engine 32 and the presentation engine 31 of the 
present embodiment. The following describes process- 
ing by the Explication manager 36 in the present embod- 
iment FIG. 38 is a flowchart showing processing lay the 
application manager 36 in the fifth embodiment. 
[0197] The flowchart of FIG. 38 is an improvement of 
the flowchart of FIG. 27. The improvement is the addition 
of a step S24 between step S2i and step S22, and ex- 
istence of a step Si 01 that is executed w^en the result 
of step S24 is "YES". 

[0198] Atstep 824, the application managers© Judges 
whether or not a JIVIF player instance exists in the work 
memory 37, and if a JMF player Instance does not exist 



in the woiic memory 37, moves to step 322. If a JMF 
player instance does exist in the work memory 37, the 
application manager 36 moves to step Si 01. At step 
Si 01 , the applkjation manager 36 judges whether or not 

•5 a playbackcompletion event has been output by the play- 
back control engine 32, and if a playback completion 
event has been output, deletes the Java player instance 
in the work memory (step SI 02), and notifies the module 
manager 34 that the Title has ended (step S26). If the 

10 application manager 36 does not make this notification, 
the loop processing composed of step S21 to step S24 
is repeated. 

[0199] In Uie above fiowchan, as long as a JivlF player 
instance exists in the work memory 37 (YES at step 824), 
« step 822 and step S23 are skipped. For this reason, the 
Title is interpreted as continuing even if all applications 
are terminated, 

[0200] In this way, according to the present embodi- 
ment, the application manager 36 is able to grasp the 

20 point at which the playback time of two hours has 
elapsed. This enables a menu whose condition for being 
displayed is the end of PL playback to be displayed, and 
enables control to be perfonmed such that a branch is 
performed to anoUier Title in response to an operation 

ss performed with respect to the menu. 

(Sixth Embodiment) 

[0201] The sixth embodiment relates to an improve- 
so ment in providing data management tables in SD-J ob- 
jects. 

[0202] A data management table (DMT) is a table in 
which each of Java archive files to be loaded into the 
local memory 29 on the Title time axis thereof is in cor- 

35 respondence with a ,'ead attribute and a read priority lev- 
el. "Living in local memory 29" refers to a state in which 
a Java archive fiSe that constitutes the application can be 
read from ttie local memory 29 and transferred to the 
work memory 37 in the Java virtual machine 38. FIG. 39 
shows an example of a data management table. As 
shown in FIG. 39, the data management table shows a 
'life cycle" of each application, an "application ID" that 
identifies the application that has the iife cycle, a 'read 
attribute" of the application and a 'read priority" of the 

« application. 

[0203] The concept of life cycle that exists in the ap- 
plication management table described earlie r is the same 
as concept of the life cycle of the data management table. 
Altbou^ the it may seem pointless to provide the same 

50 concept as the application management table in the data 
. - management table, there is a purpose to this. 

[0204] FIG. 40 shows an execution model that as- 
sumes a BD-J object. The execution model in FiG. 40 is 
composed of a BD-ROM, the local memory 29, and the 

S5 Java viraial machine 38, and shows the relationship be- 
tween the BD-ROM. the local memory 29, and the work 
memory 37. An an-ow myl indicates reading between 
from the BD-ROM to the local memory 29, and an arrow 
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my2 Indicates reading from the local memory 29 to the 
v/ori< memory 37, The explanatory notes with each of the 
arrows show !he timing with which that reading is per- 
formed. According to the explanatory notes, the reading 
from the BD-ROM to the local memory 29 is so-called 
"pre-reading", and must be performed before the appli- 
cation is required. 

[0205] Further it can be seen from the ei^lanatory 
notes that the reeding from the local memory 29 to the 
worl< memory 37 is performed when the application be- 
comes required. "Becoming required" denotes (1) the 
point in time at which the life cycle of the application ar- 
rives, and (2) a call for the application is instructed by 
another application or the application manager 36. 
[0206] An arrow my3 indicates freeing of an area oc- 
cupied by the application in the work memory 37, and an 
arrow my4 indicates freeing of an area occupied by the 
^plica^on in local memory 29. The explanatory notes 
indicate the timing with which this reading is perfoimed. 
As can been seen from the explanatory notes, the work 
memory 37 is freed simultaneously with termination of 
the application. On the other hand, the local memoiy 29 
is freed at the point when the appiication is no longer 
required by the Java virtual machine 38. Tlie point when 
the application is no longer required refers notto the 'ter- 
mination point", but to the point, after the termination 
point, when there is no possibility that the application will 
be rerun, in other words, the point when the Title ends. 
Of this reading and freeing, the point at which the work 
memory 37 is freed is determined based on the life cycle 
in the application management table. However, it is not 
possible to specify the point before the appllcaUon is re- 
quired, or the point, after termination, when ttiere is no 
possibility that the application wil! be renjn. For this rea- 
son, the cycles for which the application live are written 
separately 1o the application management table in the 
data management table during the authoring stage, in 
orderto specify the various points on the overall time axis 
of the disc content. In other words, by defining the point 
before an appSicatlon is required as a start point of the 
life cycle in the data management table, and defining the 
point wrtien tfiere is no possibility that the application wiil 
be reojn as the end point of ttie life cycle in the data 
management table, the described changes in what the 
local memory 29 stores can be specified at the authoring 
stage. This is the significance of defining the data man- 
agement table. 

[0207] The following describes how the life cycles in 
the local memory 29 are defined in the data management 
table. Here, the disc content to be produced is composed 
of three Titles (Title#1 , Tlt!e#2, and Title#3). These Titles 
are assumed to use the local memory 29 with the timing 
on the time axes of the Titles as shown in FIG. 41 B, In 
this case. Java archive files that constitute applications! 
and application#2 are read to the local memory 29 at the 
staring point of the TrtleSI time axis, and are kept in the 
local memory 29 while the Title#1 time axis continues. 
Next, the Java archive file that constitutes applicationSI 



is freed frwn the local memory 29 at the start point of tfie. 
Title#2 time axis, and. In place of applicationf(2, the Java 
archive fiie that constitutes application's is read to the 
appfication memory 29 and kept therein (Hereinafter, 

5 "application" is used in the same sense as the Java ap- 
plication files that constitute an application). Here, the 
data management table is written as in FIG. 4iA, and 
witing tiie application IDs of the applications in corre- 
spondence with the life cycles of the applications makes 

JO it possible to express which application should be kept 
in the local memory 29. In FIG. 41 A, the applicationID of 
applicationifl is in written cotre^ondenoe with Title* 1, 
the applicationID of app!ication#2 is In conrespondence 
withTitleSi and Title#2, and the applicationID ofthe«p- 
pltoation#3 is written in con-espondence with T(tle#3. De- 
fining correspondence in this way means that the tem- 
poral change of the occupation of the local memory 29 
is specified by the author. 

[0208] In ternis of the combination of the data man- 

^0 agement table and the application management t^le, It 
is preferable that the life cycles specified In the applica- 
tion management table are defined in small units of play- 
back, while the life cycles ^ecifiad in the data manage- 
ment table are rough units of playback. The rough units 

^5 of playback are preferably units of non-seamless play- 
back, such as Titles and PLs. On the other hand, the 
small units of playback are preferably units of seamless 
playback such as chapters in PLs, If the life cycle of an 
application is set for each Title and each PL, the appii- 

30 cati on win exist i n the local memory 29 , and th erefore will 
be in a state of being able to be extracted at any time 
during plaj^ack of a Title, If the application is able to be 
extra«ed at any time during playback of the Title, the 
application will be able to be read to the work memory in 

''5 the virfejai madiine immediately, even if the life cycle of 
the application is set in small units of playback. This 
means that the application will be abie to be executed 
smoothly even if It Is run and terminated frequently. 
[0209] The following describes read attributes. 

-JO [0210] Aithough the Java archive files shown in FIG. 
2 were assumed to be recorded in a separate recording 
area to the AVCIips, this is simply one example. There 
are cases in which Uie Java archive fifes are embedded 
in the recording area occupied by the AVCLips on the 

-fs BD-ROfJ!. There are two wnbedding formats: carousels 
and interleave units. 

[0211] Here, the carousel format denotes converting 
data to a broadcast method in which the same content 
is repeatedly broadcast in order to realize interactive 

50 broadcasting. Although Bie BD-ROM does not store 
broadcast data, the 8D-ROM stores Java archive files in 
thefashlonofacarouselbroadcastmetfiod inthepresent 
embodiment. FIG, 42 shows how Java archive files are 
embedded accorciing to the carousel method. The first 

55 row is the Java archive files embedded in an AVClip, and 
the second rov^shows the data made into a section. The 
thind row shows the data made into TS packets, and the 
fourth row shows the TS packet series the constitutes 
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the AV clip. The data that has been made into a section 
and into TS pacl<ets ("D" in FIG. 42). is embedded in the 
AVCIip. The java archive fiSes multiplexed on the AVClip 
as carousels are read at a low band. This iow-frequency 
reading takes considerable time, typic^ly two to three s 
minutes, and therefore the playback apparatus spends 
two to three minutes reading the Java archive files. 
[021 2] FIG. 43A shows how Java archive files are em- 
bedded according to interleaving. The first row is an AV- 
CIip into which the Java archive files are to be embedded , ' o 
the second row Is the Java archive tiles interleaved in 
the AVCIip, and the third row shows the arrangement of 
the AVCiip in the recording area of the BD-ROM. As 
shown In FIG. 43 A, the Java archive files to be embedded 
in the stream are Interleaved, and recorded between the is 
separate parts (AVCIip 2/4 and AVCIip 3/4 in FIG, 43A) 
that constitute XXXXX,m2ts that constitutes the AVCLip. 
This interleaving enables the Java archive files muiti- 
plexed on the AVCiip to be read with relatively high fre- 
quency compared to the carousel format. The playback so 
ar^aratus can read the Java archive files In a relatively 
short amount of time due to this high-frequency reading. 
[0213] The Java archive files In the carousel fonnat or 
the interieaved format are not preloaded, but are loaded 
into the local memory 29 of the playback apparatus when 
the cun-ent playback position reaches the part of the AV- 
CIip recording area on the BD-ROM in which the Java 
archive files in the carousel format orthe interleaved for- 
mat are embedded, instead of the manner shown in FIG. 
2, the Java archive fiies may be recorded in the manner 30 
shown in FIG. 42 or in FiG. 43A. A read at&ibute may be 
set as shown in FiG. 43B, The types of read attribute are: 
"Preload" shov/ing that the Java archive file should be 
read to the local memory 29 before Title playback; 
"LoadCarousel" showing that ttie Java archive file 3S 
should be read in carousel format during Trtle playback, 
and "Load. 1 nterLeave" showing that the Java archive file 
shouldbe read inlnterleaved format duringTitlepia^^ack. 
Although the read attributes are expressed wltti suffixes 
showing whetherto read in carousel format orintetfeaved 
format, these suffixes may be omitted. 
10214] Aspedfic example of how life cycles are defined 
in a data management table is described with reference 
to FIGs. 44A and 44B. FIG. 44A shows an example of a 
data management table. FIG. 44B shows changes in the -'s 
storage content of the focal memory 29 according to al- 
location by the data management table. In FIG. 44B, the 
vertical axis direction shows the occupied area of the 
local memory 29, and the horizontal axis shows »ie PL 
time axis of one Title. The life cycle of applcationttl is so 
defined in the data management table as the entire PL 
time axis of the one Trtle, and therefore applications! 
occupies area in the local memory 29 during Chapter#l 
to Chapter#6. The life cycle of application#2 is defined 
in the data management table as ChapSerSi and Chap- ss 
ter#2 in PL#1 in the Titie, and therefore app!icatfon#2 
occupies area \rt the local memory 29 during Chapter#l 
to Chapter#2. The life cycle of appilca«onf#3 Is defined 



in the data management table as Chaptef*4 and Chap- 
terMS in PL#1 in the Title, and therefore application's 
occupies area in the local memory 29 during Chapter#4 
to Chapter#5. This completes the description of iife cy- 
cles in the data management table. 
[0216] Next, the read priority leva! is described. The 
read prio rity level is a priority level that determines prio rity 
with respect to reading to the local memory 29. The pri- 
ority level has one of a plurality of possible values. If two 
levels of priority are provided, the read priority level is set 
to a value showing Mandatory or a value showing Op- 
tional. In this case. Mandatory shows a high read priority 
level and Optional shows a low read priority level. If three 
levels of priority are provided, the read priority level is set 
to a value showing Mandatory, or a value shovi/ing Op- 
Eional:hlgh orOptionaf:low. Mandatory shows the highest 
read priority level, Optional:high shows a medium read 
priority level, and Optional:low shows a low read priority 
level. A specific exampie of how read priority levels are 
defined in the data management table is described with 
reference to FIGs. 45A and 45B. The local memory 29 
is assumed to have niemory scale such as shown in FIG. 
45 A. FiG. 45A shows a comparison of memory scales of 
the local memory 29 in both a new playback apparatus 
and an old playback apparatus. An arrow mkT shows the 
memory scale in an old playback apparatus, and an an-ow 
mk2 shows the memory scale in a new playback appa- 
ratus. Comparing the anrows, the memory scale of the 
local memory 29 in the new playback apparatus is esti- 
mated to be at least three times that of the old piayback 
apparatus. In view of such varia^on in memory scale, 
applications are classified into two groups s uch as shown 
in FIG. 45B. The first group is applications that should 
be read regardtess of the memory scale {applications 1, 
app!ication#2). The second group is applications that it 
is not desirable to read in an old playback apparatus, but 
it is desirable to read in a new playback apparatus (ap- 
plicaion#3, appncatlon#4). If applications to be read are 
classified into these two groups, a read priority level of 
Mandatory is set with respect to applications belonging 
to the fonnef group, and read priority level of Optional is 
set with respect to applications belonging to the latter 
group, FIQ, 458 shows an example of the data manage- 
ment table in which read priority levels have been set. If 
applicationffi to appiication#4 are recorded on the BD- 
ROM with the data management table having been set 
in this way, playback can be guaranteed in playback ap- 
paratuses of various memory scales, and playback ap- 
parat uses with large memory scales can be made to piay 
applications using data Uiat is even larger in size. 
[021 6] This completes the improvement relating to the 
recording medium of the present embodiment. Tlie fol- 
lowing describes an improvement relating to the playback 
apparatus of the present embodiment. The applfcatlon 
manager36 performs processing according to procedure 
shown in FIG. 46, to respond to the described improve- 
ment in the recording medium. 
[0217] FIG. 46 shows processing for preload control 
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by ttie application manager 36. The flowchart includes local memoiy 29 unless the results of the judgments at 
loop processing In which the following Is Treated: the stepSl20andstepS121 are "YES°. With an old playback 
application manager 36 reads the data marsagement ta- apparatus that has a small memory sca^e, the result of 
ble of the Tltie to be played (step S1 1 1), sets, as appli- the judgment at step S121 will be "NO' after approxi- 
cation i. the application that has the highest read priority 5 mately two orthree applications have been read, but with 
level in the data application management table and that anewplaybackapparatusthathasa largememoryscale, 
has the lowest appiicationID (step Si 12), and after judg- a result "NO" will not be produced in the judgment at step 
ments at step Si 13 and step S1 1 4, preloads applicaSon Si 21. In this way, only applications that are "Mandatory" 
i into the local memory 29 {step 811 5). The application are read to the local memory 29 in an old playback ap- 
manager36repeatsthisprocessinguntl!theresu(tofthe »o paratus, whereas appiicafions that are"Mandatoiy"and 
judgment at step S1 1 6 is "NO" and the result of the Judg- applications that are 'Optional" are read to the local mem- 
ment at step Si 1 7 is "NO". ory 29 In a new playback apparatus. 
10218] At step S11 3, the application manager36 judg- [0225] Step SI 22 is executed if the result of the judg- 
es whether or not the read attribute of application i is ment at step S120 is "YES". If an application j that tias 
Preload, and at step-Si 14. judges whether the read pri- is the same application ID and a high read priority level 
ority level is Mandatory or Optional. If the read attribute exists, the application managerSB judges whether or not 
isjudgedtobe Preload at step S1 13 and the read priority the total of the remaining edacity of the local memory 
level is judged to be Mandatory at step 81 14, the appli- 29 and the size of afplication j exceeds the size of ^ 
cation ispreloaded into the localmfflnory29{stepSll5). plication i (step 3122). and if the total exceeds the size 
If the read attribute is judged to be Load at step S1 1 3, so of application i, preloads ^plication i into the local mem- 
step 31 14 and step Si 15 are skipped. ory36byoverwrrtingapplicaaonj(stepS'!23). Ifthetotai 
[021 9] Of the two steps that specify requireme nts for does not exceed the size of application i. the processing 
entfing the loop processing, at st^ Si 1 6 the application moves to step S 1 1 6 without preloading application i into 
manager36judgeswhetherornotanapplication kexists the local memory 29. 

that has the next highest applicationID after s^DpNcation [0226] An example of read processing at step S1 1 5 

i and has the same read priority level as application i. If and step Si23 is described with reference to FIG. 47A. 

such an application k exists, the appltoation manager 36 FIG. 47A shows an example of a data management table 

sets this application k as application i (step Si 19). assumed in this specific example is based. Each of three 

[0220] Of the tv;o steps that specify requirements for applicaSons in FIG. 47A is stored in three files that have 

ending the loop processing, at step S1 17 the application so the same ^plication ID (appiicationlD=1), butmunjally^ 

manager 36 judges whether or not any applications that different read priority levels (Mandatory, Optionahhigh, 

have the next lowest read priority level in the data man- Optional; low), if adata management tabie set in thisway 

agemenl table, and If such applications exit, the applica- • is the target of processing, the application that has a read 

tion manager 36 selects the one among the applications priority level '(Mandatory" is read to the local memory 29 

having the next lowest read priority level that has the 35 according to step S1 15. However, applications having 

lowest applicationID, as application k (step Si 18), and the read priority level •Optional" will be read after the 

sets application k as application i (step Si 19). The judgments at step 8120 to step Si 22, at step Si23.Un- 

processing from step 8113 to step Si 15 is repeated as like step 5115, at step SI 23 an application !s preloaded 

long as the resultof step Si 16 and step Sn 7 is "YES'. so as to overwrite an application having the same appli- 

The processing of the flowchart ends when there are no io cationlD that already exists in the local memory 29, and 

longer any relevant applications at step Si 1 6 and step therefore one of a plurality of applications is read e'xclu- 

sively to the local memory 29. 

[0221] Step S120 to step S123 are processing that is 

executed when the read fwiority level is judged to be Op- i) When reading the application having the read pri- 
tionai at step 8114. ority level "Optional: high" after the application hav- 
[0222] Atstep S120, the applcation managerSS judg- ingthe readpriori!y1evel"Mandatory" hasbeen read, 
eswhetherornotanappiicationjexiststhathasthesame the application having the read priority level "Man- 
applicafionlD and has a high priority level. datory" remains in the local memory 29 if the result 
[0223] Atstep Si 21 , the application manager36 judg- of the judgment at step SI 22 is "NO". When reading 
es whether or not the remaining capacity of the local so the application having the read priority level "Optlon- 
memoty 29 exceeds the size of application I. If the result al: high" after the application having Ihe read priority 
of step SI 20 is "NO" and the result of step Si 21 Is "YES". ' ' level "Mandatory" has been read, if the result of the 
applicatio n Ms preloaded to the local memory 29 at step judgment at step 8 1 22 is "YES", the application hav- 
S 1 1 5. If the result of step SI 20 is "NO" and the result of ing the read priority level "mandatory" is overwritten 
step S121 is "NO*, the processing moves to step S1 16 ss withtheapplicationhavlngthereadpriority level"Op- 
without application i being preloaded in the local memory. tiona!;high-, and the applcation having the read pri- 
[0224] By processing in Siis way, data for w^ich the ority level "Opfional high" remains in the local mem- 
read priority level is Optional is not preloaded into the ory 29. 
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li) When reading the application having the read pri- 
ority level "Optional: low" after the application having 
Ihe read priority level "Optionalrhigh", the application 
having the read priority level 'mandatory" remains 
in \he local memofy 29 If the result of the judgment s 
at step Si 22 is "NO". When reading the ^plication 
having the read priority level "Optional riow'afterthe 
application having the read priority level "Optional; 
high", if the result of the judgment at step SI 22 is 
•YES", the application having the read priority level to 
"Optionai: high" is overwritten with the application 
having the read priority level 'Optional: low' (step 
S123), and the application having the read priority 
level "Optional :low" remains in the local memory 29. 

^S 

[0227] Processing to overwrite the applications in the 
local memory 29 is repeated as long as the capacity of 
the local memory 29 allows it, and therefore the storage 
contents of the local memory 29 change in the following 
manner: Mandatory = Optional: high => Optional: low, as so 
shown in FIG. 47B. Java archive files of differing sizes 
are loaded into the local memory 29 in accordance with 
the memory scale, and consequently, Java archive files 
can be loaded into the local memory 29 such that those 
having thumbnail images with minimum necessary res- 
oluUon are loaded In the case of a playbacl< apparatus 
hawng a small memory scale, those having medium-res- 
oluUon SD images are loaded In Uie case of a plaj^ack 
apparatus having a medium memory scale, and those 
having high-resolution HD images are loaded in the case so 
of a playback apparatus having a lai^e memory scale. 
Loading in this way enables images of differing resolu- 
tions to be displayed in accordance with the memory 
scale, and gives the author a greater range of expression 
In cfeating Titles, 3S 
[0228] FIGs. 48A to 4SC show a specific example of 
reading processing that references a data management 
table. FIGs. 48A to 48C showtwo applications that have 
been assigned the same appllcationID (af^licationSS). 
One of the two applications is embedded In an AVClip 'lo 
and has a read priority level "Mandatory", and the other 
is recorded as a separate fife to the AVClip and has a 
read priority level of "Optional*. Since the former appli- 
cation is embedded in the AVCLp. the life cycle of the 
en^edded par! is defined as "nt!e#1 :chapter#4-#5". Of 
the applications, application#2 and application#3 are as- 
signed the read attribute 'Load", application#2 has a life 
cycle "Chaptei*1 to ChapterS2', and application#3 has 
a life cycle "Chapter#4 to Chapter#5'. Therefore, at a 
given point on the Title time axis, one of the two is always so 
exclusively in the local memory 29. FIG, 48B shows ap- 
plioation#2 and application #3 stored exclusively at differ- 
ent points on the Title time axis. This is in consideration 
of plai^ack in a playback apparatus that has only the 
minimum necessary memory scale. With the data man- ss 
agement table having the described contents as the tar- 
get of processing, the application manager 36 performs 
processing different to that in the above FIG. 46, In ac- 



cordance with the memory scale. 
[0229] The latter application has a read priority level 
"Load" , and therefore is loaded into the local memory 
29. With such processing, the application manager can 
load data into the local memory 29 as long as there is 
sufficient memory scale for ^plications having the read 
attribute •Mandatory". The problem here is the timing with 
which a playback apparatus having a large memory scale 
reads. Despite havinga large memory scale, such a play- 
back aRjaratus cannot read applicationi#3 until reaching 
Chapte(#4-Chaptei* 5, and therefore the memory scale 
is wasted. In view of this problem, in the data manage- 
ment table of FIG. 48A, the same application's is record- 
ed on the BO-ROM, having being given a read attribute 
showing "Preload", and the appiications are given the 
same applicationlD. 

[0230] The former application has a read priority level 
"Optional", and therefore is preloaded only if the result 
of step Si 21 Is "YES" (step S115). This enables a play- 
back apparatus having a large memory scale to load an 
application the same as an application embedded in an 
AVClip to the local memory 29 without watting to reach 
Chapter#4-Chapter#5 of Title#1 (FIG. 480). 
[0231] This completes the processing when preload- 
ing. The tollowing describes She procedure f orprocessing 
when loading. 

[0232] FIG. 49 shows the procedure for load process- 
ing based on a data management tabSe. This flowchart 
indudes loop processing composed of step S131 to step 
Si 33 that is repeated while playback of a Title continues. 
[0233] At step S131, theappHcation man age r 36 judg- 
es whetherornotthestart of the life cycle of an application 
having an run attribute showing AutoRun has been 
reached. If the start of the life cycle has been reached, 
the application manager 36 sets the application hawng 
the run attribute showing AutoRun as an application q 
(step Si 34). issues a run instnjclion instmcting running 
of application q to the Java >^'rtual machine 38, and caus- 
es the application q to be read from Uie local memory 29 
to the work memory 37 (step 8135), 
[0234] At^epSI 33, theapplicationmanager36 judges 
whether playback of all PL^ in the Title has ended. This 
judgment is made based on whether or not a playback 
completion event is received from the playback control 
engine 32, as shown in Ihe fifth embodiment. If playback 
has ended, the processing in the present flowchart ends. 
[0235] At step Si 32, the application manager 36 judg- 
es whether or not there has been a call from an applica- 
tion currently running. It there has been a call, the appli- 
cation manager 35 sets ihe call destination application 
as application q (step Sl36), and judges whether or not 
the cun-ent playbackposition corresponds to the life cycle 
of application q in the application management table 
(step 81 37). if the current playback point does not cor- 
respond to the life cycle of application q, display is per- 
formed to indicate a run failure (step S148), and the ap- 
plication manager 36 returns to the ioop processing com- 
posed of step SI 31 tostepSl33. If the current playback 
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point corresponds to 8ie life cycle of application q, the 
application manager 36 performs load processing in ac- 
cordance with the flowchart in FIG. 50. 
[0236] At step S13B in FIG. 50, the application man- 
ager 36 judges whether or not She current playback po- 5 
sition corresponds So the life cycle of application q in the 
data management table. If the current playfaaclt position 
does notcorrespondtothe lifecycle, application qcannot 
be loaded into the local nnemofy 29. In this case, the 
application manager 36 issues a njn instruction instruct- 'o 
ing running of application q, to &\e Java virtual machine 
3B. and the java virtual machine 38 reads appiication q 
from the BD-ROM to the work memory 37 directly, not 
via the local memory 29. In this case, s head scene to 
read this application occurs, and ttierefore PL playback 
is suspended (step 5145). 

[0237] If the current playback position con-esponds to 
the nfe cycle, at step S139 the application manager 36 
judges whether or not a read attribute is attached to the 
application. If there is no read attribute, this means that 
application q is either in carousel fomiat or interieaved 
format. However, application q is permitted to be put into 
the local memory 29 even if it does not have an attached 
read attribute. In view of this, reading of the application 
is perfomied with the l<nowledge that playback will be 25 
suspended. In other words, after the application is read 
from the BD-ROA/I to the local memory 29, it is then read 
to the wori< memory 37 (step S140). 
[0238] Step 8141 to step SI 46 is processing that is 
perfomied if the result of the judgment at step Si 39 is so 
"YES". At step S141 the application manager 36 refers 
to the read attribute to judge whether or not the applica- 
tion is preloaded. If the application is preloaded, the ap- 
plication manager 36 moves to step 8135. 
[0239] Step SI 42 is a jud^ent step that is executed ss 
if the read attribute is "load". At step S1 42 the application 
manager 36 judges whether application q is in carouse! 
format or Interleaved fomiat. if application q is in inter- 
leaved format, the application manager 36 makes the 
Java virtual machine execute cache sense (step S143). '>o 
If application q exists in the local memory 29, the appli- 
cation manager 36 moves to step S135, and has app\i- 
cation q loaded in the Java virtual machine 38. 
[0240] If the application is not in the local memory 29, 
exception processing such as branching to the top menu •'s 
Trtle is perfonmed (step 81 44). If the ^plication is in car- 
ousel format, the application manager 36 sets a timer 
(step S 1 48), and has the J ava vi rtual machine 38 execute 
cache sense (step Si 46) until the timer times out (step 
S147). If application q appears in the local memory 29, so 
the application manager moves to step S135, and has 
the Java wrtual machine 38 load application q. When the 
timertimes out, exception processing such as branching 
to the top menu Title is performed (step 8144). 
[0241] FIG.51 ilSustrateshowiheJavavirtualmachine ss 
38 reads applications. 

[0242] Arrows @1 and @2 indicate reading of a Java 
archive file that lives in the applicationmanagement table, 
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lives in the data management table, and has a read at^ 
tribute showing carousel format or interieaved fomiat 
The arrow ©1 indicates sensing of the local memory 29 
at steps S65 and 867. The local memory 29 perfomns 
sensing because data embedded according So carousels 
or interleaving may exist in the local memory 29. The 
arrow @2 is a read that corresponds to step 8135, and 
indicates loading from the local memory 29 to the work 
memory 37 in the case of the application existing in the 
local memory 29. The arrow with a cross (x) indicates a 
case of data not existing in the local memory 29. 
[0243] Arrows 71 and V2 indicate a read of Java ap- 
plication files that live in the application management ta- 
ble, but do not live in the data management table and do 
not have a read attribute. 

[0244] The arrow VI is a readthatcorresponds to step 
SI 45, and indicates a request for a directory read from 
the BD-ROM by the Java virtual machine 38. The arrow 
V2 indicates the reading of the Java archive file from the 
BD-ROM to the work memoiy 37 in response to the re- 

[0245] Arrows -ftl, -dZ, and *3 indicate a read of a 
Java archive fiie that lives in the application management 
table and lives in the data management table, but does 
not have a read attribute. 

[0246] Thearrow-itl isareadthatcon'espondstostep 
Si 40, and indicates a request for a directory read from 
the BD-ROM by the Java virtual nriachine 36. The amvi 
*2 indicates the reading of the Java archive file from the 
BD-ROM to the local memory 29 in response to the re- 
quest. The arrow i: 3 indicates a read of the Java archive 
file from the locai memory 29 to the work memory 37, 
[0247] As has been aescribed, according to the 
presentembodimen:, the number of applications that are 
kept in the local memory 29 at any one time is specified 
so as to be no more than a predetemiined number, thus 
effectively avoiding cache mistakes when reading from 
She local memory. Since applications are guaranteed to 
be read without cache mistakes, playback of AVCLips 
does not have to be stopped in order to read an applica- 
tion from Oie BD-ROfv/i, Eliminating inten'uptions in play- 
back of AVClip guarantees seamless playback of AV- 
CLips. 

(Seventh Embodiment) 

[0248] In the third embodiment, the time axis of non- 
AV Titles we re set based on the I ife cycle of applications. 
However, applications run unstably, and may fail to run 
or terminate abnormally. The present embodiment pro- 
. poses a fail safe stmcftjre for when an application fails 
to run or terminates ^normally. FIG. 52A shows the in- 
temal structure of a BD-J object relating to the present 
embodiment Comparing FIG. 52A with FIG, 7p, the ad- 
dition of a PlayLfst management table is new in FIG, 52A, 
[0249] FIG. 52B shows an example of a PlayList man- 
agement table. The PlayList management table shown 
in FIG. 52B is composed of PlayList specifications and 
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piayback attributes of the specified PlayLists. Each spec- 
jficatron of a PL shows a PL that is playable on the Title 
time axis of a corresponding Title. Each playback at- 
tribute shows whetherornotthe correspondi ng specif i ed 
PL should be automasically played simultaneously with 5 
the start of playback of the corresponding Title (A PL 
automatioaiiy played in this way is refen^dtoas a default 
PL). 

[0250] The foliowin g describes how a Title time axis is 
specified according to !he PiayList management table, fo 
With reference to FiQs. 53A to 53D. FIG. 53A shows the 
Title time axis of a non-AV Title in acase of the playbacl< 
attribute being seE to show non-automatic playback. In 
this case, because the default PL is not played, the Title 
time axis is set based on the life cycle of the application 's 
in the same way as with a non-AV Title. 
[0251] FIG. 53B shows a Title time axis of a non-AV 
Trtle ior which the piayback attribute is set to AutoPlay, 
If the piayback attribute is set to showAutoPlay, the play- 
back control engine 32 starts playback of the default PL so 
simultaneously with the start of playback of Uie non-AV 
Title. However, this Title tBne axis is set based on the PL 
time axis regardless of whetherthe applteatlon runs nor- 
mally or terminates abnomnally. 

[0252] F!G,53Cshowsacaseofiheplayi>ackattribute ss 
beingsettoshow'AutoPlay" in the PlayList management 
table, and the application tenminatlng abnomnally. Al- 
though the abnormal temiination of the application 
means that no applications are mnning, playback of the 
default PL continues. The PL time axis of the default PL ao 
becomes the Title time axis in this case also. 
[0253] FIG. 53D shows a case of the playback attribute 
being set to show "AutoPlay" in the PlayList management • 
table, and the main application failing to mn. In this case, 
also, the playback control engine 32 piays ttie default PL 35 
regardless of whether the application fails to run or not, 
and Uierefore the time axis of the default PL becomes 
the Trtle time axis. 

[02541 In this way, if the playback attribute is set to 
"AutoPlay" in the PlayList managementtable, something 
will be shown on the screenwhiie a Java application is 
being run, even if ittakes somewhere in the vicinity of 5 
to 10 seconds to run the Java application. This state of 
something being shown on the screen compensates for 
the startup delay when executing a Title, 
[025S| The above is an Improvement relating to a re- 
cording medium of the present embodiment The follow- 
ing describes an improvement relating to a playback ap- 
paratus of the present embodimeni. 

[0256] FIG. 52C shovjs how the playback apparatus 50 
processes in a case of a PL existing whose playback 
attribute Is set to "AutoPlay" in the PlayList management 
table of a branch destination Title. As shown in FIG. 52C, 
H a PL whose playback attrib ute is setto "AutoPlay" exists 
in the PlayList management table of a branch destination ss 
Title, the application manager 36 of the BD-J module 35 
instructs the playtsack contro I engine 32 to start playback 
of the AutoPlayPL directly after branching to the Trtle. In 



this way, a PL whose playback attribute is "AutoPlay'ls 
instructed to be played directly after branching to a Titie. 
[02S7J The application manager36 performs process- 
ing according to procedure shown in FIG. 54, to respond 
to the described improvement in ttte recording medium. 
[0258] FIG. 54 is a flowcdiart showing processing by 
the application manager 36 relating to the present em- 
bodiment This fiowchart is the flowchart of FIG. 38 wi»i 
the addition of step S103 andstep SI 04 before step S21 . 
the addition of step S100 between step S21 and step 
S22, and the addition of step Si 05 between step S23 
and step S26. 

[0259] At step SI 03, the application manager 36 judg- 
es whether or not the playback attribute in the PiayList 
management table of the corresponding Title is "Auto- 
Play". If the piayback attribute is "AutoPlay" , the appli- 
cation manager 36 has the playback control engine 32 
start playback control with respect to the default PL (step 
S104). 

[0260] At step SI 00, the application manager 36 judg- 
es whether or not playback is being performed by pres- 
entadon engine 31 , and If plaj^ack is being perfomned 
by the presentation engine 31 , moves to step SI 01 . 
[0261 J Step S 1 05 is a judgme nt step that is perf omied 
in the case of "YES" at step 323 or "NO" at step 825, 
and is for showing whether or not the playback attribute 
is "AutoPlay*. If the playback attribute is not "AutoPlay", 
the application manager 36 notifies the module manager 
34 of the end of the Title. If the playback attribute is 
"AutoPlay* , the appifcation manager 36 moves to step 
S'SOl and continues the processing. 
[0262] FIG. 55 illustrates how playback is performed 
with the playback attribute being set to "AutoPlay* in the 
PlayList management table. Here, the Title that should 
be played is a non-AV Trtle that includes a game appli- 
cation in which falling tiles are stacked upon each other. 
If the playback attribute is setto "AutoPlay" in the PlayList 
management table of this non-AVTrtle, the playback con- 
trol engine 32 will start playback of the default PL Since 
execution of the game application and playback of the 
default PL are perfomied in parallel, a composite image 
in which the game application screen is in the foreground 
and the playback image of the default image is in the 
background is displayed as shown in the upper row of 
the left side of FIG. 55. The game application is forcedly 
tenninated by the application manager 36 but playback 
of the default PL continues, and therefore something of 
the Title is shown on the screen. By specifying the play- 
back attribute in the PiayList management table in this 
way, operation can be maintained without hang-ups or 
blackouts even if a game application in a non-AV Title 
tenminates abnormally. 

(Eighth Embodiment) 

[0263] in the first embodiment, BD-J objects have two 
tables: adata managementtable andan appiteation man- 
agement table. However, the present embodiment dis- 
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closes an embodiment in whidi these two tables are in- 
tegrated Into one table. In view of this rntegraflon, the 
read attributes i n th e data management table are omitteci, 
and instead a "Ready" attribute is provided as one of the 
run attributes, as shown in FIG. 56A. The "Ready" at- s 
tribute is a type of run attribute that indicates that an ap- 
plication it to be preloaded into the local memory 29 in 
preparation for a call from another application or a call 
from the application manager 36. 

[0264] FIG, 56B shows the relationship between run io 
attributes and the treatment of applications. Applications 
were treated in the first embodiment according to (1) 
whether or not the application is pretoaded, (2) whether 
the application is run automatically when the current play- 
back position reaches the effective cycle of the appiica- i5 
tion or whetherthe application is run in response to acail 
from another application, (3) whether the application is 
loaded in accordance with the progression of the Title, 
and whether the application is fiving. TTie five states 
shown in FIG. 56B eppearas a result of these differences, so 
The run attribute is set to "AutoRun* when the application 
is So be preloaded and automatically run, and when the 
application is to be loaded and automatically run. 
[026S] On the other hand, the run attribute is set to 
"Ready" when the application is to be preloaded or load- 5" 
ed, and the ain field In the table shows "call run". 
10266] Note that there is no type showing that an ap- 
plicalion lives in the work memory 37 but is not loaded 
to the local memory 29. This is because the life cycle in 
the wor1< memory 37 andthe life cycle in the local memory so 
29 are incorporated with each other in She application 
and data management table. 

[0267] Since a "Ready" attribute has been added to 
the types of run attributes, the application manager 36 
perfomis processing to preload applications for which 35 
the ain attribute is set to "AutoRun" and applications for 
which the run attribute is set to "Ready" before playback 
o! the Title. This makes it possible to perfomi processing 
to load applications to the local memory without providing 
read attributes. -jo 
[0268] FIG. 57 illustrates how the Java virtual machine 
38 of the eighth embodiment reads applications. RG. 57 
Is based on the reading shown in FIG. 51, 
[0269] An-ows (gJI and ©2 indicate a read of a Java 
archive file that lives in the appiicadon and data manage- 'is 
ment table, and whose run attribute is set to "Ready". 
[0270] The arrows *1 , A2, and ■sSrS indicate a read of 
an application that lives inthe application, and data man- 
agement table, and whose run attribute is "Persistent". 
[0271] The arrows @1 and @2 and the arrows '(!^. so 
•f!2. and TirS are defined in FIG. 51 , but reads corrEspondr 
ing to the an-ows Vi and V2 in FIG. 51 do not exist in 
FIG. 57. This is because the application management 
table and the data management table have been Inte- 
grated to form the application and data management ta- 5S 
ble, and therefore the combination of an application living 
in the application management table and not living in the 
data management table cannot be expressed. 
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[0272] As had been descr^bed, according to the 
present embodiment, the data management table and 
the application management table are able to be inte- 
grated into one table (the application and data manage- 
ment table); thus simplifying processing by the applica- 
tion managerSS. Note that the application and data man- 
agement table may be furUier simplified by omitting the 
read priority levels therefrom, 

(Ninth Embodiment) 

[0273] !n the first embodiment, applications were read 
into the local memory 29 by ref ening to read priority levels 
and reading in accordance with these read priority levels, 
thus giving an order of priority to the reads. In contrast, 
the ninth embodiment ejqiresses read priority levels ac- 
cording to a combination of information that signifies "Op- 
tional" and values from 0 to 255. 
[0274] FIGs. 58A and 58B show an example of the 
read priority levels of the ninth embodiment. The values 
255 and 128 are examples of the read priority ieveis from 
0 to 255, and show that application#2 has a higher read 
priority level that applicationffS in the present example. 
[0275] The application manger 36 in the present em- 
bodiment reads applications ha\^ng a read priority level 
showing "Mandatory", to the local memory 29 first, as in 
the first embodiment. 

[0276] The applicationmanager36subsequent!y judg- 
es whether or not the capacity of the local memory 29 
exceeds the size of applications having a read priority 
level showing "Optional". If the capacity exceeds the size 
of the applications, the application manager 36 read ex- 
plications having the read priorrty level showing "Option- 
al" to the local memory 29. Ifthe capacity does not exceed 
the size, the application manager 36 reads, from among 
the dataconstituang the applications, the application hav- 
ing a high value expressing the read priority level, to the 
local memory 29. The application manager 36 subse- 
quently reads an application having a low value express- 
ing the read priority level, to the remaining area in tfie 
local memory 29. 

[0277] This enables some applications treated as "Op- 
tional" to be stored in the local memory 29 of the playback 
apparatus if the local memory 29 lacks sufficient capacity 
to store all applications. 

(Tenth Embodiment) 

[0278] in the first embodiment, the applicatior^ manag- 
er 36 loads one of applications having the same applica- 
tionlD exclusively to the local memory 29 in accordance 
with the priority levels. However, ttie tenth embodiment 
realizes exclusive loading by assigning group a^liutes 
to applications. FIGs. 59A and 59B show a data man- 
agement table in which group attributes are assigned. 
There are two possible settings of the group attribute; 
"exclusivity group existent' and "exdusivity group non- 
existent". In the case of "exclusivity group existent", the 
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group number of the group is defined in the data man- 
agement table, (n fiG. 59A, "-"torTrtieSI shows ttiat an 
exclusivity group does not exist On the other hand, 
'group#l " for Titieffa and Title#3 shows that an exciusiv- 
ity group exists and that TiHefta and Title#3 belong to an s 
exclusivity group called "group#1". The above is an inn- 
provement relating to a recording medium of the present 
embodiment, 

[0279] The playback apparatus of the present embod- 
iment first reads applications to the local memory 29 
based on the data management table, and then verifies 
■the group attributes of the plications in ttie local mem- 
ory 29. If at least two appiicatlons belonging to the same 
exclusivity group exist in the local memory 29, one of the 
applications is deleted from the local memory 29. 
[0280] This improves the usage efficiency of the local 
memory 29. A specific example of an exclusivity group 
is a group composed of a launcher application and an 
appSication that is run by the launcher applioation. Since 
ttis number of applications run by the launcher applica- 
tion is, in principle, limited to one, only the launcher ap- 
pllcaGcHi and one other application should exist in the 
tocaf memory. If three or more applications exist in the 
local memory 29, it is necessary forthe appiication man- 
ager 36 to perfomn processing to delete the extra appli- 
cation or applications from the local memory 29. To this 
end. each application is provided with a group attribute, 
and the application manager 36 checks whether the ap- 
plications that exist in the local memory 29 are a launcher 
application and one other application. 30 
[0281] FIG. 59A shows access to the local memor/ 29 
based on the application management table. In FIG. 59A, 
the group attribute of appiication#2 and applicationflS, 
which have read priority levels set to "Optional", is 
•gfoup#r. This means that ttiese applications belong to ss 
the same exclusivity group. Of the three applications, ap- 
p[lca«on#1 is the aforementioned launcher application, 
andappiicatlon#2 and appIication#3 are applications that 
are run by the launcher applteation, Therefors, group at- 
tributes are assigned such that only one of applioationS2 
and application#3 exist in the local memory 29. The ap- 
plication manager 36 refers to the group attributes of ap- 
plication#2 and applicationSS to perfonn processing to 
delete one of these two applications from the local mem- 
ory 29. Oeieing one of the applications generates space ''S 
in the local memory 29. 

{Eleventh Embodiment) 

[0282] In the first embodiment an individual application so 
management table is provided for each Title. However, , - 
the present embodiment prqooses changing the unit of 
allocation of application management tables. FIG. 60 
shows variations of the unit of allocation of application 
management tables. In FIG . 60, the first row shows three ss 
application management tabies recorded on a BD-ROM, 
the second row shows Title units, the third row -shows 
disc units, and the fourth row shows a disc set composed 



of a plurality of BD-RO(^s. Arrows in FIG. 60 illustrate 
allocation of the application management tables. Refer- 
ring to these arrows, it can be seen that application man- 
agement tablesSI, #2 and #3 in the first row are respec- 
tively assigned to Tttlefll , Title#2 and Title#3 in the sec- 
ond row. Furthermore, application management tableS4 
is assigned to a unit of a disc, and application manage- 
ment tabie#5 is assigned to the entire disc set. Using 
units that are larger than Titles are the units of allocation 
of the applioation management tables enables applica- 
tions that live while one BD-ROM is loaded In the play- 
back apparatus to be defined, and applications that Rve 
while one of a plurality of BD-ROMs is loaded in the play- 
back apparatus to be defined. 

Remarks 

[0283] The above descs^tion by no means shows the 
implementation of all configurations of the present inven- 
tion. Impiementation of the present invention is still pos- 
sible according to implementation of configurations that 

carry out the following modifications (A), (B), (C), (D) 

The inventions pertaining to the claims of the present 
application range from expanded disclosure to general- 
ized disclosure of the plurality of embodiments disclosed 
above and the modified configurations thereof. The de- 
gree of expansion or generalization is based on the par- 
ticular characteristics of technical standards in the tech- 
nical field of the present invention at the time of the ap- 
plication. 

(A) In all of the embodiments, an optical disk pertain- 
ing to the present invention is implementedas a BD- 
ROM. However, the optical disk of the present in- 
vention is characterized by the recorded dynam'ic 
scenarios and the Index Table, and these character- 
istics are not dependent on the physical properties 
of a BD-ROM. Any fomn of recording media is appli- 
cable as long as there exists the capacity to recorcl 
dynamte scenarios and Index Tables, For example, 
optical disks such as DVD-ROM, DVD-RAM, DVD- 
RW, DVD-R, DVD+RW, DVD-i-R, CD-R. CD-RW, 
andthe like, and opticai-magneiic disks such as PD, 
M O and the like are applicable. Semicon ducto rcards 
such as compact flash cards. PGM-CIA cards and 
the like are also applicable, as are (i) magnetic re- 
cording disks such as flexible disks, SupeiOisk, Zip, 
ClikI andthe like, and (ii) removable hard disk drives 
such as ORB, Jaz, SparQ, SyJet, EXFley, microdrive 
and the like, Furthemnore, the recording medium 
may also bie a built-in hard disk. 

(B) Mhough the playback apparatuses in all of the 
embodiments output AVCIips recorded on a BD- 
ROMto a TV after decoding., the playback appara- 
tus may be structured from ianly a BD-ROM drive, 
and file TV may be equipped with ail of the other 
elements. In Uiis case, the playback apparatus and 
the TV can be incorporated I nto a h ome network con- 
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nected using IEEE1 394. /Wso, although the playback 
apparatuses ]n the embodiments are of a type used 
after connecting to a teievision, integral display-play- 
back apparatuses are also applicable. Furthermore, 
the playback apparatus may be only those part of s 
the pSayback apparatuses of the enfibodiment that 
perform essential parts of the processing. Because 
these playback apparatuses are all inventions dis- 
closed in the specification of the present application , 
acts invoSving the manufacUire of playback appara- 'O 
tuses based on an interna! structure of the plaj^ack 
apparatuses shown in the first to third embodiments 
are implementations of the inventions disclosed in 
the specificalion of the present applfcation, Acts that 
involve transfen-ing (retail when cost is involved; a is 
gift when no cost is involved), lending, or importing 
of playback apparatuses shown in the first to third 
embodiments are also implementations of the 
present invention. Acts that involve approaching the 
generai user about transfer, rental or the Sike by so 
means of show-window displays, catalogue solicita- 
tion, pamphiet distribution and the like are also im- 
plementations of these playback apparatuses. 

(C) Because of the infonnation processingby acom- 
puierprogram shown in each of the flowcharts being ?5 
realized specifically using hardware resources, a 
computer program showing the processing proce- 
dures in the flowchart fonns an invention in its own 
right. Although all of the embodiments show embod- 
iments that relate to the implementation of computer 3o 
programs pertaining to the present invention in an in 
incoTDorated fomn in the playback apparatuses, the 
computer programs shown in the first to third em- 
bodiments may be implemented in their own right, 
separate from the playback apparatuses. The imple- 35 
mentaSon of the computer programs in their own 
right includes acts that involve: (1 } production of the 
programs, (2) transference of ttie programs, either 
gratuitous or otherwise, (3) lending of the programs, 

(4) importing of the programs, (5) provicflng the pro- -fo 
grams publicly via bi-directional electronic commu- 
nications drcults, and (6) approadiing the general 
user about transfer, rental and the like by means of 
show-window displays, catalogue solicitation, pam- 
phlet distribution, and so forth. ■is 

(D) Consider that the element of "time" relating to 
the steps executed in time -series in each of the flow- 
charts is a required item for specifying the invention. 
If this is the case, then the processing procedures 
shown by the flowchart can be understood as dis- so 
closing the usage configurations of the playback 
method. Execution of the processing in flie flow- 
charts so as to achieve the original objects of the 
present invention and to enact the actions and ef- 
fects by perfomiing the processing of the steps in 55 
time-series is, needless to say, an implementation 

of the recording method pertaining to the pfesenl 



(E) A Menu(ChapteriWenu) for displaying a list of 
Chapters, and a MOVIE object ifor controlling the be- 
haviorof this maybe recorded on the SD-ROM. such 
that this Menu(ChapterMenu) can be branched to 
from the top menu. Furthermore, this Menu (Chap- 
lerivlenu) may be called according to a press of a 
Chapter key amo n g t he keys of th e remote co ntroller. 

(F) When recording on a 8D-R0M, extension head- 
ers preferably are appended to TS packets structur- 
ing AVCIips. These extension headers, which are 
called TP_extra_header, Include an •Arrival_Time„ 
Stamp" and a "copy_permisslOf>_indicatof" and have 
a 4-bit type data lengtti. TP_extra_header-aaached 
TS packets (heranafter, ^breviated to "EX-at- 
tached TS packet") are arranged into groups of 32 
packets, and written into three sector. Each group 
comprising 32 EX-attachecfTS packets is 6,144 
bytes in length (=32*192), and matches the 6,144- 
byte size of three sectors (=2048'3). The grouping 
of 32 EX-anaohed TS packets contained in three 
sectors is referred to as an 'Aligned Unit". 

A playback apparatus 200 transmits Aligned Units 
in transmission processing as describedbelow, 
when used in a home network connect via 
I EEE 1 394. That is, a device on the side of the sender 
removes the TP_extra_header from each of the 32 
EX-attachedTS packets included in an Aligned Unit, 
and outputs the TS packets after encoding the TS 
packet body based on a DTCP standard. When out- 
putting TS packets, isodironous packets are insert- 
ed between all adjacent TS packets. The positioning 
of isochronous packets is based on times shown in 
the Arrival_Time_Stamp in eac^ TP_extra_header. 
Hie playback app^feis 200 ou^uts a DTCP_De- 
scrtptor following the outputting of the TS packets. 
The DTCP„Descrip!or shows a copy permissibility 
settingin each1P„extra_header, Here, iftheDTCP_ 
Descriptor is described so as to show "copy prohib- 
ited", TS packete will not be recorded on ottier de- 
vices when used in a home network connected via 
IEEE1394. 

(Q) Although digital streams recorded on a recording 
medium in the embodiments are AVCIips, the digital 
streams may be VOBs (Video Objects) complying 
with a DVD-Video standard or a DVD-Video Record- 
ing standard. V08s are program streams compliant 
with ISO/IECI 3818-1 obtained by multiplexing video 
and audio streams. Also, video streams in AVCIips 
may be MPEG^ format, WMV fomiat, or the like. 
Furthermore, audio streams may be a Linear-PCM 
format, Dolby-AC3 format, MPS format, or MPEG- 
AAC format. 

(H) The video works in each embodiment maybe ob- 
tained by encoding an analog video signal broadcast 
according to analog broadcasting, or may be stream 
data constituted from a transport stream broadcast 
according to digital broadcasting. 
Furthemiore, content may be obtained by encoding 
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an analog'digital video signal recorded on a video 
tape. Moreover, content may be obtained by encod- 
ing an analog/digital video signal imported directly 
from a video camera. Alternatively, the content may 
be a digitaf work distributed by a distribution server. 
(!) The BD-J module 35 may be a Java platfonm in- 
stalled in a device In order to receive satellite broad- 
casts. If the BD-J module 35 is this Java piatJomi, a 
playback apparatus according to the present inven- 
tion shares processing as MHP-ose STBs. 
Furthemnore, the BD-J module 35 may be a Java 
■ platform installed in a device in orderto perform mo- 
bile telephone processing controls. If the BD-J mod- 
ule 35 is this Java piatform, a plsybacl( apparatus 
according to the present invention shares process- 
ing as a mobile telephone. 

(K) In the layer model, the HDMVmode may be po- 
sitioned on the BD-J mode. This is because espe- 
cially the analysis of the dynamic scenario in the HD- 
MVmodeandtheexecutionofthe control p rocedure 
based on the dynamic scenario put light load on the 
playback apparatus, and there is no problem in ex- 
ecuting the HDMV mode on the BD-J mode. Also, in 
the development process of the playback apparatus 
or a movie work, the operations can be guaranteed 
by only one mode. 

Further, the playback process maybe executed only 
in the BD-J mode. This is because as shown in Em- 
bodiment 5, a playback control can be perfonned in 
synchronization wiBi a playback of a PL in the BD-J 
mode, and therefore the HDMV mode may not nec- 
essarily be provided. 

(L) A navigation command may be provrided for a 
interactive graphics stream that is to be multiplexed 
on an AVCLip, in orderto realize branching from one 
PL to another PL. 

Industrial Appiicability 

[0284] The playback apparatus of the present inven- 
tion may be used personaliy as in a home theatersystem. 
However, the playback apparatus of the present inven- 
tion may also be used industrially since the internal struc- 
ture thereof is disclosed in the embodiments described 
above, and it is apparent that the playback apparatus of 
thepresent invention will be mass-produceo. Forthis rea- 
son, the playback apparatus of the present invention has 
industri^ applicability. 



Claims 

1. A recording medium on which is recorded a plurality 
of tities between which branching is possible, and at 
least one applicaUon, 

wherein each application is a program written in a 
virtual machine-ofienled programming language, 
and a life cycle in which each application can be ex- 



ecuted by a virtual machine is specified in advance, 
each title inciudes a management table, and 
each management table shows one or more of the 
applications that has a life cycle bound to the title. 

5 

2, The recording medium of Claim 1 , wherein 

archive files are recorded on the recording medium, 
each an;hh/e file storing data and a program that 
constitute a given application, 
' 0 each af^lication that has a lif e cycle bou n d to a title 
is expressed according to a combination of an iden- 
tifier of the archive file that stores the application, 
and a title number that uniquely identifies the titi.e. 

'5 3. A playback apparatus that simultaneously perfomns 
playback of a title that inciudes a digital stream, and 
execution of an application, comprising: 

a module manager operable to control branch- 
^0 ing between a plurality of titles; 

a playback control engine unit operable to piay 
a digital stream that b^ongs to one of a plurality 
of titles; and 

an application manager qjerable to, each time 
25 a branch between titles occurs, perf onn run con- 

trol so as to njn an applteation that has a life 
cycle bound to a branch destination title and ter- 
mination control so as to terminate an applica- 
tion that does not have a !ife cycle bound to the 
30 branch destination title. 

4. The playbadi apparatus of Claim 3, wherein 
each title includes an application management table 
that shows at least one application that has a life 

35 cycle bound to the title, and 

the run control by the application manager includes 
control for, when a branch between titles occurs, re- 
femng to the application management table of the 
branch destination fflle to judge whether an applica- 

10 tion exists that has a Ufe cycle bound to the branch 
destination title, and, only when an application that 
has a life cycle bound to the branch destination title 
exists, mnnrng the application that has the life cycle 
bound to the branch desUnation. 

IS 

5. The playback apparatus of Claim 4, wherein 

the run control by the application manager includes 
control for, v\*en an applcation call has been made 
by an application being run in one title, refemng to 
so the application management table of the title to judge 
whether or not a call destination application has a 
life cycle bound to the title, and activating the call 
destination application only when the call destination 
application has a life cycle bound to the title. 

55 

6. The playback apparatus of Claim 3, wherein 
each title includes a t^le that shows at least one 
application that has a life cycle bound to the title, and 
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the temiination contro! by the application manager 
includes control for, when a branch between titles 
occurs, referring to the table of the branch destina- 
tion title tojudgewhetheranyof applications that are 
ainning does not have a life cycle bound to She s 
branch destination title, and only if one or more of 
the running applications does not have a life cycle 
bound to ttie branch destination title, performs con- 
trol to terminate the one or more applications. 

w 

. 7. The playback apparatus of Clam 3. wherein 

the branch is realizedby an application interface that 
instructs the playback apparatus to jump to a title, 
the application includes a procedure to cail the ap- 
plication interface, and is 
the module manager executes the branching in re- 
sponse to the virtual machine decoding the proce- 
dure. 

fi. The playback apparatus of Claim 3, wherein 

playback of the digital stream by the playback control 
engine includes trick playback and normal playback, 
and 

the application manager starts run control of the ap- 
plication upon normal playback of the digital stream 
of the branch destination title steiiing. 

9. A program that causes a computerto simuUaneo usly 
perfomi playback of a title that Includes a digital 
stream, and execution of an application, wherein 30 
the program causes the computerto, each time a 
branch between titles occurs, perform run control so 

as to run an application that has a iife cycle bound 
to a branch destination title and termination control 
so as to terminate an application that does not have ss 
a life cycle bound to the branch destination tide. 

10. A playback method that causes acomputertos'mul- 
taneousiy perform playback of a title that includes a 
digital stream, and execution of an application, 
wherein 

the playback method causes the computer to, eadn 
timeabranch between titles occurs, perfomi runcon- 
&ol so as to run an application that has a life cycle 
bound to a branch destination Ctle and termination 
control so as to terminate an application that does 
not have a life cycie bound to the branch destination 
title. 
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